The alternate screen terminal emulator plague

November 29, 2011

There is one bit of behavior in modern X environments that drives me up the wall: the use of 'alternate screens' in terminal emulators (and in programs). That's probably obscure to most people, so let me put it the other way; what drives me up the wall is when I edit a file in vi or view it in a pager like less, quit, and all of the text that I was just looking at instantly disappears in favour of what was on the screen before I started whatever it was.

(Having this happen in less is especially infuriating, since less's entire purpose is showing me information. But the moment I quit, I can't have it.)

What is happening is not the fault of vi, less, and so on, or at least not exactly. Unix systems have terminfo, which is essentially a big database of terminals and escape sequences that programs can send to make them do things; two of the defined terminfo capabilities are escape sequences that you are supposed to send when your full screen program starts and stops. Many terminal emulators (and a certain number of real terminals) support an alternate screen, and the people who wrote terminfo database entries for them decided that full screen programs should always use this alternate screen so they put the escape sequences for 'switch to alternate screen' and 'switch to main screen' into the initialization and de-initialization sequences. When programs like vi, emacs, and less dutifully send the escape sequences that the terminfo database tells them to, they shoot your foot off.

My personal opinion is that this is an unfortunate example of the slow fossilization of X terminal emulators. xterm probably does this because some real terminal had its terminfo set up this way in the depths of time, and everyone else has probably slavishly copied how xterm works. No one has stopped to ask if the end result makes sense and is usable, because if they had a great many people would have told them that it doesn't and isn't.

(Xterm gets partial credit because it has a way to turn this off, so at least the xterm people recognize that it's a terrible idea even if they feel constrained by backwards compatibility to not fix the default.)

Unfortunately there is no general fix for this. Some programs can be told to not send the terminfo initialization and de-initialization strings; some terminal emulators can be told to ignore them. Sadly, sending the strings and paying attention to them is the default behavior; this leads to fixing a lot of programs on a lot of systems, one by one.

(For extra fun, some Unixes do things right to start with. For example, Solaris has never put the alternate screen escape sequences into their terminfo entries for xterm.)

Sidebar: the quick fixes

If you use xterm, set the XTerm*titeInhibit resource to true to make it ignore the alternate screen escape sequences. As usual, gnome-terminal has no way of controlling this.

For less, do 'export LESS=X' or otherwise give it the -X switch.

For vi, add 'set t_ti= t_te=' to your .vimrc.

(Some information taken from here. See also.)


Comments on this page:

By gsauthof at 2011-11-29 04:07:14:

Well, I guess it is a matter of taste and 'socialization'.

I have the opposite feeling: At some point I noticed that the alternating screen behavior of less/vim and so on was more and more going to be (or always was?) an out of the box default (on Linux systems) - and I liked it ('this is a sane default now', I thought). That `top` still was not alternating the screen was kind of irritating. But then working on Solaris I really hated the 'old' non-alternating-screen behavior.

For example when you have some really important command history and the commands output in the terminal screen buffer and then hit `man something` such that it is overwritten by some useless man stuff. I mean, when I am finished reading a man page I don't need to have a fragment of the content cluttering up my terminal ... ;)

Without alternating full-screen, programs destroy something what you already have on your screen - and that is not possible or expected when you execute a non-full-screen command like `ls`, where new command output can only push the oldest output out of your terminal history buffer.

From 46.144.78.131 at 2011-11-29 11:03:25:

in the comments if you follow the advice from a Benjamin you will get your desired behaviour: http://fixlog.blogspot.com/2006/09/stop-gnome-terminal-screen-clear.html

From 128.210.48.47 at 2011-11-29 12:37:06:

This is probably a matter of taste, but I personally agree with gsauthof's arguments above. Actually, this was exactly the reason I've long ago switched from more(1) to less(1) as a pager (on all systems I use, more(1) does not switch to alternative screen, while less(1) does). And now I can use this difference creatively to my advantage: if I need to look something up in a file and want a piece of output to stay on screen afterwards, I do more file. Otherwise it's less by default.

Lev

From 121.45.240.239 at 2011-11-29 20:53:40:

I guess I've gotten used to it and have my workflow organised so it is not a problem. As well, I personally much prefer seeing the output of previous commands when I exit a full-screen program rather than having to scroll up to see it.

My solution is two-fold (I believe I've mentioned this before, so excuse any repetition). On one desktop is a full-sized xterm with either screen or tmux, so a man page is simply a ctrl-a keypress away.

Additionally, I use a drop-down console which activates on a pre-defined keypress (I use the right-hand Windows key, I think it is called the Menu key in Windows-speak). It is hidden normally and quickly drops down when you press the Menu button, then hides itself again. This is great for quickly checking command line options or a man page. I use yeahconsole; there are others such as qterm.

~~~~Nick Coleman

Written on 29 November 2011.
« The login name problem
My mouse button bindings in fvwm, my window manager »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Nov 29 01:10:01 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.