microsoft/Terminal

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

Open

#11 078 ouverte le 29 août 2021

Voir sur GitHub
 (3 commentaires) (0 réactions) (0 assignés)C++ (3 212 forks)batch import
Area-VTHelp WantedIssue-BugPriority-2Product-Conhost

Métriques du dépôt

Stars
 (35 764 stars)
Métriques de merge PR
 (Merge moyen 27j 19h) (24 PRs mergées en 30 j)

Description

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.

image

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.

Guide contributeur