PuTTY semi-bug resize-scroll-effects

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Resizing the window does the Wrong Thing to its contents
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: tricky: Needs many tuits.
priority: low: We aren't sure whether to fix this or not.
fixed-in: r2923 e9cc32850132b0ed4bc1279200ef9a432dc8d0f5 2003-03-08 (0.54)

I (BJH) think that PuTTY's behaviour when the number of lines on the screen is changed is currently wrong. What it currently does is to keep the bottom line of the screen in a fixed position relative to the text. This means that if the window is enlarged, lines get pulled out of the scrollback and added to the screen, and if the window is shrunk, lines get pushed from the screen to the scrollback. A particularly nasty aspect of this is that if you have a large window with a shell prompt at the top and you reduce its size, the prompt disappears off the top of the window. Pulling lines out of the scrollback might also get awkward if we start storing the scrollback in a compressed format.

So what should we do? xterm's fix to the disappearing-prompt problem seems to be to delete lines from the bottom of the window when it's shrunk unless that would delete the line containing the cursor, in which case lines are deleted from the top instead. When enlarging the window, xterm pulls lines out of the scrollback just like PuTTY. I still haven't decided whether or not this is evil. In any case, it should probably be inhibited in alternate screen mode, just like copying data into the scrollback is (xterm gets this bit wrong).

Another subtlety is what to do about saved cursor positions. At present in PuTTY (and I think in xterm), if you open an 80x24 window, do something to put stuff into the scrollback, switch to the alternate screen, enlarge the window to the height of the screen and then switch back from the alternate screen, you end up with the cursor on line 24, rather than at the bottom of the screen with the text that used to be on line 24. This is clearly wrong. Richard Boulton has a patch to fix this.

(cf. `resize-no-truncate' for the case where the number of columns is changed.)

SGT, 2003-03-07: Just accepted a patch from Richard Boulton which should fix this.


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2016-12-27 11:40:21 +0000)