Mouse tracking does not respect the system's `rows to scroll` setting

[o-sdn-o]

Windows Terminal version

current main

Windows build number

10.0.19045.4894

Other Software

WSL + vim

Steps to reproduce

1. Set the rows to scroll system setting to 5.
2. Run

wsl bash -c "vim -c :h"

3. Scroll the mouse wheel.

Type :q and press Enter (repeat twice) to quit.

Expected Behavior

The cursor should move at the pace specified in the system-wide settings - 5 rows per 1 wheel step.

pwsh.2024-10-23.18-47-17_0.mp4

Actual Behavior

The cursor moves at a speed of one row per mouse wheel step.

PowerShell.2024-10-23.18-48-15_0.mp4

[zadjii-msft]

I'm surprised that this wasn't already somewhere on our backlog! I could have swore I remembered a discussion about this already, but I sure can't find it. Thanks for filing!

[lhecker]

I thought that when mouse tracking is enabled, the terminal only sends a single sequence per scroll event. Isn't sending of multiple cursor up/down sequences only a thing during the alternate scroll mode with mouse tracking disabled?

[DHowett]

Yes, this should be the case. Xterm mouse reporting reports button events, of which each wheel detent is one.

Xterm mouse reporting does not report lines scrolled.

How many lines the application scrolls when it receives a wheel detent button reports an application choice.

We can choose to treat ASB with Alternate Scroll differently, but I am not interested in changing how wheel detents are reported.

[zadjii-msft]

I assumed that this was alternate scroll mode in action, fwiw.

[DHowett]

Hm. I expect vim to use xterm mouse reporting.

It does here:

[o-sdn-o]

There is no way for an application running inside WSL (or on a remote side) to know the local system-wide scrolling settings. Moreover, for example in Midnight Commander the scrolling speed is hardcoded as 2 lines per wheel step for the viewer and editor, and 1 line everywhere else. Repeating mouse wheel reports (of any protocol) in the amount of the system-wide scrolling setting value makes such applications "live" and acceptable/comfortable when using mouse scrolling.

The only place where I see a discrepancy is Far Manager - on their side they multiply the scrolling by the system-wide scrolling setting value because they can reach it via SPI_GETWHEELSCROLLLINES.