starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Open
opened 2026-01-31 04:25:54 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 04:25:54 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Aug 29, 2021).

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.

Originally created by @j4james on GitHub (Aug 29, 2021). ### 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](https://user-images.githubusercontent.com/4181424/131259764-30dafeb4-327a-4fae-90df-3646a13f39cd.png) 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.
claunia added the Help WantedProduct-ConhostIssue-BugArea-VTPriority-2 labels 2026-01-31 04:25:54 +00:00
claunia commented 2026-01-31 04:25:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 8, 2022):

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.

@zadjii-msft commented on GitHub (Mar 8, 2022): 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.
claunia commented 2026-01-31 04:25:55 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 8, 2022):

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 https://github.com/dankamongmen/notcurses/issues/2114).

@j4james commented on GitHub (Mar 8, 2022): 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 https://github.com/dankamongmen/notcurses/issues/2114).
claunia commented 2026-01-31 04:25:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 18, 2023):

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

image

@zadjii-msft commented on GitHub (May 18, 2023): 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 > > ![image](https://user-images.githubusercontent.com/26201412/237547534-b0985848-ec39-4918-bb2b-2813adcd5a1c.png) >
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted Issue-Bug Priority-2 Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15007
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?