How to Not Overwrite Previous Terminal Contents

Question

I'm not sure if this is a duplicate, but I have no clue what to search for if it is, as I don't know the name for this phenomenon.

Basically, whenever I use vim and less on certain computers, the previous terminal contents are overwritten by the buffer of the current file (I think). If I scroll back with the scrollbar, rather than the current program's commands, I can see the previous terminal contents, but some of the previous lines have been written over by the current program. It seems like however many lines went through the buffer (I think) of, for example, vim, is how many previous lines of the terminal were overwritten. When I quit out of vim/less, those lines were still overwritten, though they show up in the history and when I press up to go "back" through the history.

However, on other computers, something quite different happens. While I am using vim or less, if I scroll up and down, I cannot see the previous lines of the terminal. In fact, on most computers where this phenomenon occurs, if I scroll back with the mouse, vim and less scroll back through the file in the current buffer, as if I pressed Ctrl-E/Ctrl-Y. When I quit vim/less, I do not see the file at all, I only see the previous contents of the terminal, as in whatever I was doing before I opened the file.

Whenever I use more, no matter what computer I use, the former phenomenon occurs, but I don't use more that much, as I like less better in every way, so I haven't tested its limits.

The computers/virtual terminals where I experienced the former phenomenon seem to be older computers and/or computers with lesser capabilities and specs, which makes sense as most people would probably want the latter, but it is probably harder to accomplish and requires more processing power and memory.

The computers with the former experience were: 2 old RedHat's at my work, that are probably from the late 2000's/early 2010's, which I accessed from a Windows 7 computer with Penguinet; Android phones/tablets with the Terminal Rex IDE where I "install the system". On most Android terminal apps, I can not get vim, less, or even vi, though I get more. When I used vagrant with Git Bash, with the default TERM value of msys, the terminal was all messed up, and I experienced most of the same behavior, but worse. When I changed TERM to cygwin or xterm, it was better.

The computers with the more desired behavior (for me) were: my newest laptop with Ubuntu 15.04 (yes, a cmputer with Linux preinstalled); any Linux VM I installed on my Windows 8 laptop in the past couple years, but I only got the newest versions so I don't know how old the behavior is; Git Bash on my Windows 8 laptop. Git Bash did not scroll back through the file when I scrolled with the mouse, but rather through an empty terminal, but that may have been because of settings in my vimrc/lessrc. When I quit in Git Bash, it still showed me all the previous lines and not the file.

Most of these computers were using bash, but I still experienced the newer phenomenon when I installed and used fish on my newest ubuntu computer, even when I made it the default shell, and I don't believe Git Bash is technically bash, though it could be. I believe the Terminal Rex app used bash when it installed to the system, but when I check the SHELL environment variable with other terminal apps, and with Terminal Rex without the system installed, it reports as sh.

I am interested in why these behaviors occur, but I am more interested in a way to change it to the more desired behavior. Is there a way to make the behavior of vim & less on older/less capable computers be more like the behaviors on newer ones? Also, is there a way to make Git Bash scroll back through the file rather than the blank terminal?

Bonus: Is there a way to make more behave more like less on the newer computers? Or is this just the difference between more and less? Come to think of it, is it possible that the less on the less capable computers is actually more?

Answer 1

The behavior being described is the xterm-style alternate screen. There are two cases:

• when it is used, the terminal switches to the alternate screen when you run full-screen programs such as vim.
• when not used, the terminal continues in the normal screen when running full-screen programs.

The normal/alternate screens are the same size: the visible portion of the terminal ignoring the scrollback area. You can see the scrollback using a mouse. If you do that while switched to the alternate screen, you can see the scrollback adjacent to the current (alternate) screen. After switching back, e.g., when vim exits, the previous lines are shown throughout the scrollback and current (normal) screen. There is no marker between the two.

Some aspects of the normal/alternate screen were recently discussed in What mechanism allows ViM to temporarily overwrite the entire console?

Most applications on Unix (and Linux and BSD and ...) pay attention to the TERM environment variable, which they (or a library such as ncurses) uses to retrieve information from the terminal database. In principle, one can set TERM separately for different applications to elicit different behavior (with the caveat that some applications such as vim have built-in tables to "fix" the terminal database which they may apply without warning). For example, running in a POSIX shell (or something like bash), you could type this to run vim and less with two different terminal descriptions:

TERM=vt100 vim foo.c
TERM=xterm less foo.c