Enable alternate scroll mode by default

[jaminthorns]

I was really pleased to see that proper support for the alt screen buffer has landed in the latest preview release (thanks to #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.

[zadjii-msft]

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.

[j4james]

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.

[phil-blain]

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 ?

[zadjii-msft]

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)

[DHowett]

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).

[jaminthorns]

@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".

[DHowett]

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

[eugenov]

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

[tomsri01]

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?

[xdhmoore]

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

[zadjii-msft]

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

[determin1st]

@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

[avih]

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.