Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
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.
Audit trail for this semi-bug.