The SU (scroll up) sequence should pan the viewport down
#11.078 geöffnet am 29. Aug. 2021
Repository-Metriken
- Stars
- (35.764 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 27T 19h) (24 gemergte PRs in 30 T)
Beschreibung
Windows Terminal version (or Windows build number)
10.0.18363.1500, 1.10.1933.0
Other Software
No response
Steps to reproduce
- Open a bash shell in conhost or Windows Terminal.
- Set the window height to something smallish like 24 rows.
- Execute the following commands:
for i in {1..100}; do echo $i; done; tput indn 10 - 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.