Please excuse the length of this question, but the issue has become a bit of a saga for me.

Problem is with xterm and the alternate screen, particularly when using vi (vim), but also with more or less. When in the alternate screen, internal scrolling disabled, when I scroll back to see text in the main screen, I cannot see the last window-full of lines.

It should be that the first lines above the alt screen contents, when scrolling back, are the last lines in the main screen, ending with the actual vi (or man, less, etc.) command itself. I'm used to this from many years of experience, most recently 10 years with an OSX laptop.

In the new machine (specs below), I have the term size set to 80x45. When I back-scroll one or two lines, I see not the last line I typed (the vi command itself), but the 44th line before that. After exiting vi, everything is "normal", i.e. I see all the command I/O I typed and received in the main screen, including the vi command itself, followed by the new prompt. Those 44 lines weren't visible while in the alt screen, but they still existed, as if they were "behind" the alt screen.


New computer: Dell XPS 13 9300, Ubuntu 20.04 LTS
shell: tsch
terminal: xterm
terminfo defaults:
smcup=\E[?1049h\E[22;0;0t
rmcup=\E[?1049l\E[23;0;0t
GNOME version: 3.36.3

I've tried a variety of settings I've found for the .Xresources file. It got me this far, the key one being: xterm*vt100.alternateScroll: false, which turns off that internal scrolling. The pages Computer Hope Linux xterm command and a long xterm description by Thomas E. Dickey were particularly useful (and thanks to those authors, if they read this).

Then I tried working with the terminfo definitions for smcup and rmcup. The default ones are:
smcup=\E[?1049h\E[22;0;0t
rmcup=\E[?1049l\E[23;0;0t
The first 9 characters in each represent the escape sequence to simply switch to (smcup) and return from (rmcup) the alternate screen. The second escape sequences in each (looks like same command, but different parameters) is a mystery, and I've not seen any difference in behavior with/without them.

Particularly useful are the pages Console Virtual Terminal Sequences and Thomas E. Dickey's page (link above). I demonstrated that I could control behavior getting into and out of that alt screen by changing those smcup and rmcup definitions, but could not figure out how to view the last screen-full of lines of the main screen using back-scrolling, when in the alt screen, without bad side effects. One trick was to move the screen down 45 lines before switching to the alt screen, but that inevitably left 45 blank lines in my scroll history once I exited vi even if I tried to reverse the action in the rmcup escape command sequence. Saving the cursor position or screen position before doing that, then returning to it after going back to the main screen, did not do anything useful. Also did not want to permanently encode 45 into the commands, since occasionally I resize the terminal windows. I suspect I've misinterpreted what, exactly, some of these control sequence commands are actually supposed to do, or exactly how they should be used.

The OSX machine I've been using (2010 era MacBook Pro, currently running OSX 10.10.5, standard Terminal ap, TERM=xterm-256color) shows what I consider correct behavior. It has the simplest smcup and rmcup settings in use (via infocmp in the terminal):
smcup=\E[?1049h
rmcup=\E[?1049l
i.e. switch to/exit from alternate screen, with no cursor or window positioning, and not that mystery command on the new Ubuntu machine. Nevertheless, when I scroll back one or a few lines while in vi (or less, e.g. when viewing a man page), everything up to the last main screen entry is seen, the command I executed to get me into the alt screen mode (there's actually a blank line between that command and the start of what is in the alt screen, but who's counting?). As far as scrolling is concerned, the alt screen is appended to the end of the main screen history (w/ blank line between), rather than being overlaid on top of (and hiding) the last screenful of main screen.

Minor observation potentially for diagnostics: resizing the terminal window while in a vi editing session gives odd results, as one might expect, but it does not allow seeing the missing main screen lines (one can lose lines permanently out of the main screen history, after one exits vi).

Of course, my experiments have not been comprehensive, but since the OSX Terminal smcup and rmcup are the simplest ones, I suspect my problem with xterm on Ubuntu 20.04 is elsewhere, even if it seems plausible that the some extra messing about with cursor and/or screen adjustments might do the trick. I have no clue about how much control GNOME has over xterm behavior, perhaps it is overriding something I would otherwise be able to control. I've had a cursory look at various /etc/X11 files, but nothing jumped out as relevant.

Any ideas?

I'm sure I've seen this problem before, perhaps 15 years ago with Redhat, but do not recall what I did about it (in the Redhat machine's home dir .xinitrc and .Xauthority files I see nothing relevant; I could have modified one of the /etc/X11 or other system level files, which are not currently accessible). I'm willing to try any reasonable terminal emulator, since the current behavior is frustrating. Don't need Tek4010 support, been many years since I've used those graphics windows, and don't do anything else fancy, but some built-in features of more modern software packages do drive me batty, so I do like the ability to control all functionality, like xterm allows. Gnome-terminal is easy to try, and I managed to set the basics quickly (default window size, font size, black letters on white background, couple other things), but I have not figured out how to turn off alternate screen scrolling in gnome-terminal, or even if it is possible, so it is less acceptable than xterm with my current config. But if I could do that, it seems the obvious choice since is ready to use otherwise -- if it doesn't turn out to have the same problem.

Unfortunately I have not been able to track down anyone else with this problem with xterm, or mention of it as a feature, though the general xterm "alternate screen" topic has been discussed numerous times and places. Maybe is just a typo in some setup file in the new Ubuntu 20.0.4 distribution Dell has sent out on new computers recently (if so, perhaps there are hundreds of others fuming about it, and there are about to be many postings on this issue). There are some messages on the root screen during boot, perhaps error messages, but it flicks by so fast. Haven't yet looked in the /var logs to see if I can track it down, never have liked that directory, seems low priority since everything else works.



Thanks in advance, K L Thompson.