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

Enable alternate scroll mode by default #17588

New Issue
Closed
opened 2026-01-31 05:46:50 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 05:46:50 +00:00
Owner
Copy Link

Originally created by @jaminthorns on GitHub (May 27, 2022).

I was really pleased to see that proper support for the alt screen buffer has landed in the latest preview release (thanks to https://github.com/microsoft/terminal/pull/12569). Would you consider enabling this behavior by default? I realize that you could just add a printf "\e[?1007h" to your shell startup script, but most terminals that I use have this mode enabled by default. This issue in the foot repository summarizes the issue nicely.

Originally created by @jaminthorns on GitHub (May 27, 2022). I was really pleased to see that proper support for the alt screen buffer has landed in the latest preview release (thanks to https://github.com/microsoft/terminal/pull/12569). Would you consider enabling this behavior by default? I realize that you could just add a `printf "\e[?1007h"` to your shell startup script, but most terminals that I use have this mode enabled by default. [This issue in the `foot` repository](https://codeberg.org/dnkl/foot/pulls/137) summarizes the issue nicely.
claunia commented 2026-01-31 05:46:51 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 27, 2022):

I don't think I have much reluctance to enabling this by default. I'll refer to @j4james as our resident VT (and compatibility) expert. It's not like an app that didn't request that mode is going to get anything particularly bad by getting up/down keystrokes. IDK it seems pretty sensible.

We could easily make it an opt-out behavior as well, or opt in if there's more compat issues that I'm not aware of.

@zadjii-msft commented on GitHub (May 27, 2022): I don't think I have much reluctance to enabling this by default. I'll refer to @j4james as our resident VT (and compatibility) expert. It's not like an app that didn't request that mode is going to get anything particularly bad by getting up/down keystrokes. IDK it seems pretty sensible. We could easily make it an opt-out behavior as well, or opt in if there's more compat issues that I'm not aware of.
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 28, 2022):

Every terminal I've tested that has support for alternate scroll also has it enabled by default, except for XTerm, and even XTerm has an option for that. So yeah, I'm definitely in favour of doing this. And now that the alt buffer doesn't show the scrollback, there's nothing else the scroll wheel can do anyway.

That said, if an application has a mouse tracking mode enabled (e.g. mode 1003) at the same time as alternate scroll, that mouse tracking should take precedence (or at least the most recent mode should take precedence). I don't think we're currently doing that, so it's important that we fix that first.

@j4james commented on GitHub (May 28, 2022): Every terminal I've tested that has support for alternate scroll also has it enabled by default, except for XTerm, and even XTerm has an option for that. So yeah, I'm definitely in favour of doing this. And now that the alt buffer doesn't show the scrollback, there's nothing else the scroll wheel can do anyway. That said, if an application has a mouse tracking mode enabled (e.g. mode 1003) at the same time as alternate scroll, that mouse tracking should take precedence (or at least the most recent mode should take precedence). I don't think we're currently doing that, so it's important that we fix that first.
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@phil-blain commented on GitHub (Jun 13, 2022):

I'm not sure if I should open a new issue, but I seem to notice that alternate scroll is noticeably slower than normal scrolling (e.g. scrolling in Vim is slower than scrolling the scrollback in the shell). Is this known / expected ?

@phil-blain commented on GitHub (Jun 13, 2022): I'm not sure if I should open a new issue, but I seem to notice that alternate scroll is noticeably slower than normal scrolling (e.g. scrolling in Vim is slower than scrolling the scrollback in the shell). Is this known / expected ?
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 13, 2022):

That intuitively makes sense to me - if you're using alternate scroll mode, then I'd suspect we send one ^[[A per wheel click, resulting in one line scrolled. In normal scrollback, we're usually scrolling about four lines per wheel click (depending on various settings)

@zadjii-msft commented on GitHub (Jun 13, 2022): That intuitively makes sense to me - if you're using alternate scroll mode, then I'd suspect we send one `^[[A` per wheel click, resulting in one line scrolled. In normal scrollback, we're usually scrolling about four lines per wheel click (depending on various settings)
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 13, 2022):

Right. Windows defaults to scrolling 3 lines per wheel detent, but if we translated a single wheel scroll event into three up/down events we would risk overshooting in cases where the wheel is being used to scroll things that aren't linear text buffers.

This will also manifest in applications that take over full mouse control rather than the partial control offered by alternate scroll mode: vim, for example, will scroll one line when it receives one "button 5" event (wheel).

@DHowett commented on GitHub (Jun 13, 2022): Right. Windows defaults to scrolling 3 lines per wheel detent, but if we translated a single wheel scroll event into _three up/down events_ we would risk overshooting in cases where the wheel is being used to scroll things that aren't linear text buffers. This will also manifest in applications that take over full mouse control rather than the partial control offered by alternate scroll mode: vim, for example, will scroll one line when it receives one "button 5" event (wheel).
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@jaminthorns commented on GitHub (Jun 14, 2022):

@zadjii-msft This is pretty commonly configurable:

  • Kitty: Configured by the wheel_scroll_multiplier setting.
  • Alacritty: Configured by the scrolling.multiplier setting.
  • VS Code Terminal: Configured by the terminal.integrated.mouseWheelScrollSensitivity setting.

@DHowett What I've usually seen is that alternate scroll mode is consistent with the scrollback behavior (usually more than 1 line per wheel click), and when an application takes over full mouse control, then it's usually 1 line per wheel click (probably because that's easiest to implement). I'm not sure how other terminals handle "overshooting".

@jaminthorns commented on GitHub (Jun 14, 2022): @zadjii-msft This is pretty commonly configurable: - Kitty: Configured by the [`wheel_scroll_multiplier` setting](https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.wheel_scroll_multiplier). - Alacritty: Configured by the `scrolling.multiplier` setting. - VS Code Terminal: Configured by the `terminal.integrated.mouseWheelScrollSensitivity` setting. @DHowett What I've usually seen is that alternate scroll mode is consistent with the scrollback behavior (usually more than 1 line per wheel click), and when an application takes over full mouse control, then it's usually 1 line per wheel click (probably because that's easiest to implement). I'm not sure how other terminals handle "overshooting".
claunia commented 2026-01-31 05:46:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 14, 2022):

Ah dang, you're totally right. We should make this configurable! Thanks!

@DHowett commented on GitHub (Jun 14, 2022): Ah dang, you're totally right. We should make this configurable! Thanks!
claunia commented 2026-01-31 05:46:53 +00:00
Author
Owner
Copy Link

@eugenov commented on GitHub (Nov 1, 2022):

By the way, how to add printf "\e[?1007h" to powershell startup?

@eugenov commented on GitHub (Nov 1, 2022): By the way, how to add `printf "\e[?1007h"` to powershell startup?
claunia commented 2026-01-31 05:46:53 +00:00
Author
Owner
Copy Link

@tomsri01 commented on GitHub (Nov 29, 2022):

If alternate buffer isn't enabled by default what is required to turn it on or make it turn on by default for all shell sessions?

@tomsri01 commented on GitHub (Nov 29, 2022): If alternate buffer isn't enabled by default what is required to turn it on or make it turn on by default for all shell sessions?
claunia commented 2026-01-31 05:46:53 +00:00
Author
Owner
Copy Link

@xdhmoore commented on GitHub (Apr 7, 2023):

It sounds like in bash you enable this with printf "\e[?1007h". Is it possible to enable it in powershell?

@xdhmoore commented on GitHub (Apr 7, 2023): It sounds like in bash you enable this with `printf "\e[?1007h"`. Is it possible to enable it in powershell?
claunia commented 2026-01-31 05:46:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 10, 2023):

In pwsh (7), I believe a write-host `e[?1007h will work. The syntax in earlier versions of powershell (powershell.exe) is... more annoying

@zadjii-msft commented on GitHub (Apr 10, 2023): In pwsh (7), I believe a ```write-host `e[?1007h``` will work. The syntax in earlier versions of powershell (`powershell.exe`) is... more annoying
claunia commented 2026-01-31 05:46:53 +00:00
Author
Owner
Copy Link

@determin1st commented on GitHub (Apr 9, 2024):

@phil-blain why not opening the issue in the vim repo? terminal user is able to translate wheel events to any number of lines 3 4 5 10 1, so it shall be a user configuration, not terminal.

i dont really understand what alternate scroll 1007 does, seem like a poor design to me, similar to 1005

@determin1st commented on GitHub (Apr 9, 2024): @phil-blain why not opening the issue in the vim repo? terminal user is able to translate wheel events to any number of lines 3 4 5 10 1, so it shall be a user configuration, not terminal. i dont really understand what alternate scroll 1007 does, seem like a poor design to me, similar to 1005
claunia commented 2026-01-31 05:46:54 +00:00
Author
Owner
Copy Link

@avih commented on GitHub (Jun 17, 2024):

Right. Windows defaults to scrolling 3 lines per wheel detent, but if we translated a single wheel scroll event into three up/down events we would risk overshooting in cases where the wheel is being used to scroll things that aren't linear text buffers.

I'd think the typical use case for this is to scroll or navigate in a linear text buffer, like in "less", or "nano" or other terminal editors, which, even if they support mouse mode, might not be enabled by default and/or not obvious how to configure, or might have some tradeoffs which the user prefers to avoid.

For instance, enabling mouse at the application (rightly) disables terminal selection by mouse drag (even if shift-drag still works, but less convenient), so the user might prefer to rely on alt-terminal-scroll and keep the mouse disabled at the app, so that they can select text without shift.

It's certainly possible that the user prefers one-line-at-a-time, or having other use cases (which I can't think of) where multiple-lines are counter productive, which is why it would be useful to have the number of lines configurable.

But I don't think it can be argued that scrolling one line per wheel event is great when the user prefers 3 or 5 lines at a time.

@avih commented on GitHub (Jun 17, 2024): > Right. Windows defaults to scrolling 3 lines per wheel detent, but if we translated a single wheel scroll event into _three up/down events_ we would risk overshooting in cases where the wheel is being used to scroll things that aren't linear text buffers. I'd think the typical use case for this is to scroll or navigate in a linear text buffer, like in "less", or "nano" or other terminal editors, which, even if they support mouse mode, might not be enabled by default and/or not obvious how to configure, or might have some tradeoffs which the user prefers to avoid. For instance, enabling mouse at the application (rightly) disables terminal selection by mouse drag (even if shift-drag still works, but less convenient), so the user might prefer to rely on alt-terminal-scroll and keep the mouse disabled at the app, so that they can select text without shift. It's certainly possible that the user prefers one-line-at-a-time, or having other use cases (which I can't think of) where multiple-lines are counter productive, which is why it would be useful to have the number of lines configurable. But I don't think it can be argued that scrolling one line per wheel event is great when the user prefers 3 or 5 lines at a time.
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-TerminalControl Area-VT good first issue In-PR Issue-Feature Issue-Task Needs-Tag-Fix Product-Terminal
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#17588
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?