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

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

New Issue
Open
opened 2026-01-31 08:13:30 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 08:13:30 +00:00
Owner
Copy Link

Originally created by @o-sdn-o on GitHub (Oct 23, 2024).

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

https://github.com/user-attachments/assets/81ccadb8-454c-44a9-bff6-9a046c0ab1d8

Actual Behavior

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

https://github.com/user-attachments/assets/aad547ef-c99d-4b32-9002-b35f26091c63

Originally created by @o-sdn-o on GitHub (Oct 23, 2024). ### 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. https://github.com/user-attachments/assets/81ccadb8-454c-44a9-bff6-9a046c0ab1d8 ### Actual Behavior The cursor moves at a speed of one row per mouse wheel step. https://github.com/user-attachments/assets/aad547ef-c99d-4b32-9002-b35f26091c63
claunia commented 2026-01-31 08:13:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2024):

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!

@zadjii-msft commented on GitHub (Oct 23, 2024): 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!
claunia commented 2026-01-31 08:13:32 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 23, 2024):

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?

@lhecker commented on GitHub (Oct 23, 2024): 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?
claunia commented 2026-01-31 08:13:32 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2024):

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.

@DHowett commented on GitHub (Oct 23, 2024): 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.
claunia commented 2026-01-31 08:13:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2024):

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

@zadjii-msft commented on GitHub (Oct 23, 2024): I assumed that this was alternate scroll mode in action, fwiw.
claunia commented 2026-01-31 08:13:33 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2024):

Hm. I expect vim to use xterm mouse reporting.

It does here:

Image

@DHowett commented on GitHub (Oct 23, 2024): Hm. I expect vim to use xterm mouse reporting. It does here: ![Image](https://github.com/user-attachments/assets/980bd4be-c7bf-46b5-b839-8f9f4bd3ded6)
claunia commented 2026-01-31 08:13:33 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Oct 23, 2024):

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.

@o-sdn-o commented on GitHub (Oct 23, 2024): 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`.
claunia commented 2026-01-31 08:13:33 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2024):

the scrolling speed is hardcoded as 2 lines per wheel step

Well that's not good! Terminal cannot know that, so if it sends 3 (or 5!) wheel down events, it'll scroll 6 (or 10!) lines. I rather think this is an argument not to do what you are proposing.

@DHowett commented on GitHub (Oct 23, 2024): > the scrolling speed is hardcoded as 2 lines per wheel step Well that's not good! Terminal cannot know that, so if it sends 3 (or 5!) wheel down events, it'll scroll 6 (or 10!) lines. I rather think this is an argument _not_ to do what you are proposing.
claunia commented 2026-01-31 08:13:33 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Oct 23, 2024):

This is very much the case with touchpads/mice with precise scrolling, as with them it is possible to scroll line-by-line, despite the fact that the system-wide setting is greater than one, it works surprisingly smooth even with 10 lines per wheel step.

@o-sdn-o commented on GitHub (Oct 23, 2024): This is very much the case with touchpads/mice with precise scrolling, as with them it is possible to scroll line-by-line, despite the fact that the system-wide setting is greater than one, it works surprisingly smooth even with 10 lines per wheel step.
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-Input Area-TerminalControl Issue-Bug Priority-3 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#22449
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?