GNOME Bugzilla – Bug 591648
Don't clear the screen when switching to the alternate screen
Last modified: 2021-06-10 14:14:50 UTC
Currently when the command is received to switch to the alternate screen, the code always clears the alt screen and homes the cursor. This behavior is wrong, and makes it difficult to use most of the fullscreen programs in Linux. E.g., when you're viewing a document with less, and then exit, the text you were reading disappears when you exit and return to the main screen. Usually you can issue the command sequence to flip back to the alternate screen and re-read the text, but libvte destroys it for no obvious reason. In the original VT100 and Xterm, none of this behavior was automatic, and it was up to the termcap/terminfo definition to include whatever clear/home command sequences should be issued when entering and exiting fullscreen mode. The library should not be performing any actions that were not explicitly requested by the user/application.
Created attachment 140622 [details] [review] Simple patch It would be better to just delete the offending lines, of course.
Can you tell me how to test the xterm behavior?
I use the aliases in my .cshrc to toggle back and forth: xt0 echo -n '^['; echo -n '[?47l' xt1 echo -n '^['; echo -n '[?47h'
That doesn't look right. Where's the \e in there? When I echo that, I see: ^[[?47l which is hardly surprising. Also, I think I need to remove the clear from termcap to be able to test the patch, right? Can you tell me which entry that is? Thanks,
The ^[ is the literal escape character, use \e instead if that works for you. In terminfo you need to fix the smcup and rmcup properties. In termcap the corresponding ones are ti and te, respectively.
Committed the patch. We still seem to be saving cursor pos when switching, which xterm doesn't do. But I'm not inclined to fix that right now.
(In reply to comment #6) > Committed the patch. We still seem to be saving cursor pos when switching, > which xterm doesn't do. But I'm not inclined to fix that right now. Thanks, sounds fine.
Created attachment 146610 [details] Screenshot of the problem Hello, this change broke less 436 on my system. Whenever I use less to check a file with less line than my terminal window I can see the contents of the previous run of less until I press a key who force a redraw (up/down arrows, home/ned, pgup/pgdown, etc.). See the attached screenshot, with each successive run I can see the file I've just open AND the output of the previous run; in this case I'm using the same file but this happens even with a different ones, with possibly security implications ('gpg -d encrypted-passwords.gpg|less', then 'less innocuous-short-file.txt', oops, my passwords!).
Sounds like your termcap/terminfo definition is missing the clear-screen command in its init sequence. You should tell what terminal type you're using.
What does xterm do?
I can actually reproduce it myself. Will revert.
This sounds like a bug in less. less 429 doesn't behave that way.
*** Bug 600913 has been marked as a duplicate of this bug. ***
commit e07acb1b6cf310e3600389ebf0c3da4e17dbc9bb Author: Behdad Esfahbod <behdad@behdad.org> Date: Sun Nov 8 12:04:16 2009 -0500 Revert "Bug 591648 - Don't clear the screen when switching to the alternate This reverts commit c6d9bf421f12911298d921314ced64661f6b63bd. That commit introduced issues with less. Xterm doesn't have those problems. Need to figure out what's going on before committing this again.
Created attachment 183455 [details] xterm difference using infocmp -d Sorry, I forgot about this. I was using a customized terminfo which moved the clear command into smcup/rmcup (instead of leaving it in is2/rs2). That fixes the issue with less.
Comment on attachment 140622 [details] [review] Simple patch Setting patch status.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/1683.