Scroll sideways while holding the shift key and scroll fast while holding the alt key

[g-dg]

This PR adds support for the shift (horizontal scroll) and alt (fast scroll) key modifiers while scrolling.

Unfortunately, it doesn't work in every terminal. Here are my testing results with some terminals:

Testing results with various terminals

Terminal	Horizontal scroll wheel	Shift + vertical scroll	Alt + vertical scroll	Alt + horizontal scroll wheel	Alt + shift + vertical scroll	Notes
Windows						(Windows 11)
Windows Terminal	❌	❌	✅	❌	❌	only sends escape codes for regular and fast vertical scroll
Windows Console Host	❌	❌	✅	❌	❌	only sends escape codes for regular and fast vertical scroll
VSCode	❌	❌	✅	❌	❌	only sends escape codes for regular and fast vertical scroll
mintty	✅	❌	✅	✅	❌	shift + vertical scroll moves the cursor up and down (???) and shift + alt + vertical scroll moves the current line up and down
Linux						(Arch with KDE on Wayland)
VSCode	❌	❌	✅	❌	❌	only sends escape codes for regular and fast vertical scroll
Alacritty	✅	✅	✅	✅	✅
COSMIC Terminal	✅	✅	✅	✅	✅	horizontal scroll wheel is inverted
Ghostty	✅	✅	✅	✅	✅	scrolls very fast with precision scrolling, but this seems to also be a problem in other command-line utilities that support mouse scrolling
GNOME Console	✅	✅	✅	✅	✅
GNOME Terminal	✅	✅	✅	✅	✅
kitty	✅	✅	✅	✅	✅
Konsole	❌	❌	❌	❌	❌	Holding shift while vertical scrolling doesn't change the scroll axis, and scrolling with horizontal scroll wheel does nothing except when holding alt which causes it to scroll vertically fast
LXTerminal	✅	✅	✅	✅	✅
MATE Terminal	✅	✅	✅	✅	✅
QTerminal	❌	❌	❌	❌	❌	Holding shift while vertical scrolling doesn't change the scroll axis, and scrolling with horizontal scroll wheel does nothing except when holding alt which causes it to scroll vertically fast
Xfce Terminal	✅	✅	✅	✅	✅
XTerm	✅	❌	✅	✅	❌	Doesn't send escape codes for shift + scrolling

Not tested:

• Mac OS

I didn't try any other terminal mouse tracking modes. For all I know, there may be one that gets more terminals to work, but changing it will probably mess up a whole bunch of other stuff.

This does change the side-scrolling from 3 characters to 7 characters. Scrolling horizontally by 7 characters seems to be about the same as what VS Code does and fast scrolling is a 5x multiplier by default in VS Code. I wouldn't mind other people's opinions on these values though.

Cool project, BTW.

[lhecker]

I......... I didn't know Alt+Scroll / Shift+Scroll did that. How did I not know this? I've been scrolling like an absolute amateur all my life. A monkey with a keyboard. A life on snooze.

[lhecker]

Also, I just saw that your PR is from Feb 20. I apologize that I ignored it - I'm not actually sure why. I love the test matrix btw!

[lhecker]

This multiplication logic should go into tui.rs. Specifically, here:

edit/crates/edit/src/tui.rs

Line 623 in 3afb4f7

next_state = self.mouse_state;

(You need to make next_scroll a mutable variable for that.)

The reason for that is that input.rs' only concern is providing platform-independent input events. When we later add a fully customizable key binding editor, your key bindings should still have almost raw access to the input events. This allows a user to e.g. change the multiplier when Shift/Alt is held during scrolling.

Right now, all of the key binding logic is hardcoded in tui.rs, so it makes sense if these two key bindings also go there.

[g-dg]

Sounds good. Would it also be a good idea to move the base scroll amounts (3 lines & 7 characters) to tui.rs as well?

I think that if fast scroll multiplication should be abstracted in the TUI layer, then the base scroll amounts should probably also be abstracted in the TUI layer.

[g-dg]

@microsoft-github-policy-service agree