After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591648 - Don't clear the screen when switching to the alternate screen
Don't clear the screen when switching to the alternate screen
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 600913 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-08-13 05:08 UTC by Howard Chu
Modified: 2021-06-10 14:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Simple patch (508 bytes, patch)
2009-08-13 05:13 UTC, Howard Chu
needs-work Details | Review
Screenshot of the problem (123.98 KB, image/jpeg)
2009-10-30 23:45 UTC, Giacomo Perale
  Details
xterm difference using infocmp -d (2.90 KB, text/plain)
2011-03-15 18:46 UTC, Howard Chu
  Details

Description Howard Chu 2009-08-13 05:08:26 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.
Comment 1 Howard Chu 2009-08-13 05:13:07 UTC
Created attachment 140622 [details] [review]
Simple patch

It would be better to just delete the offending lines, of course.
Comment 2 Behdad Esfahbod 2009-08-13 09:17:51 UTC
Can you tell me how to test the xterm behavior?
Comment 3 Howard Chu 2009-08-13 09:29:18 UTC
I use the aliases in my .cshrc to toggle back and forth:

xt0	echo -n '^['; echo -n '[?47l'
xt1	echo -n '^['; echo -n '[?47h'
Comment 4 Behdad Esfahbod 2009-08-13 19:06:15 UTC
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,
Comment 5 Howard Chu 2009-08-13 19:13:21 UTC
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.
Comment 6 Behdad Esfahbod 2009-10-24 00:20:13 UTC
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.
Comment 7 Howard Chu 2009-10-24 00:38:32 UTC
(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.
Comment 8 Giacomo Perale 2009-10-30 23:45:58 UTC
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!).
Comment 9 Howard Chu 2009-10-31 00:44:57 UTC
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.
Comment 10 Behdad Esfahbod 2009-10-31 02:40:00 UTC
What does xterm do?
Comment 11 Behdad Esfahbod 2009-10-31 02:40:55 UTC
I can actually reproduce it myself.  Will revert.
Comment 12 Howard Chu 2009-10-31 02:54:22 UTC
This sounds like a bug in less. less 429 doesn't behave that way.
Comment 13 Behdad Esfahbod 2009-11-08 02:20:50 UTC
*** Bug 600913 has been marked as a duplicate of this bug. ***
Comment 14 Behdad Esfahbod 2009-11-08 17:12:11 UTC
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.
Comment 15 Howard Chu 2011-03-15 18:46:46 UTC
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 16 Christian Persch 2011-08-16 17:52:21 UTC
Comment on attachment 140622 [details] [review]
Simple patch

Setting patch status.
Comment 17 GNOME Infrastructure Team 2021-06-10 14:14:50 UTC
-- 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.