The SU (scroll up) sequence should pan the viewport down

[j4james]

Windows Terminal version (or Windows build number)

10.0.18363.1500, 1.10.1933.0

Other Software

No response

Steps to reproduce

1. Open a bash shell in conhost or Windows Terminal.
2. Set the window height to something smallish like 24 rows.
3. Execute the following commands: for i in {1..100}; do echo $i; done; tput indn 10
4. Scroll back to view the lines that have been moved off screen.

Expected Behavior

There should be no gap in the sequence of numbers.

Actual Behavior

There are numbers missing from the sequence at the point where they've scrolled off screen.

The problem here is that there are two ways in which the SU escape sequence is typically implemented in Linux terminals. Most terminals, including XTerm, will pan the viewport down, as if you'd executed a linefeed at the bottom of the window. Lines at the top of the window will be moved into the scrollback buffer, and nothing is lost.

On VTE-based terminals, and Konsole, the SU escape sequence will just scroll the buffer contents up, constrained within the visible area. This is equivalent of deleting lines from the top of the window, so anything that scrolls off screen is lost. And that's the behavior that we're currently matching.

From a DEC VT-compatibility point of view, I don't think either interpretation is correct, so that's not a deciding factor. But the reason I think we should be matching XTerm, is because the indn terminfo capability is defined as SU, and the ind capability is defined as a linefeed control, so I think there is an expectation that indn should produce the equivalent of multiple linefeeds.

If we aren't going to do that, then we probably shouldn't be using xterm-256color for our TERM value.

[zadjii-msft]

This looks vaguely like #3673, but I'll mark it up for investigation regardless. I think we used to do this at some point, and either decided to stop, or maybe we implemented margins better and that regressed this, can't be sure.

[j4james]

Yeah, I think it would have the same effect as #3673, although it's a totally different cause. This affects conhost, while #3673 is a limitation of conpty, which doesn't understand margins (and that should eventually be fixed by pass-through mode).

I also suspect this one is less likely to be encountered, considering VTE and Konsole work the same way as us. It's not entirely hypothetical though (see dankamongmen/notcurses#2114).

[zadjii-msft]

Another theoretical effect:

Windows Terminal version

1.16.10261.0

Steps to reproduce

1. Run other program, generate many lines of content(Like benchmark)
2. Scroll down or up the wheel(The disappearing row must be moved to an invisible area before it can be seen again)
3. Some lines will disappear