Vim/Neovim/tmux scroll way too fast with trackpads

[reissbaker]

Environment

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18362.0 Microsoft Windows NT 10.0.18362.0

Windows Terminal version 1.0.1401.0.

I'm curious whether or not this is trackpad-related, so FWIW I'm using a Surface Book and scrolling with the trackpad.

EDIT: I tried with a normal mouse plugged into the USB port instead of the trackpad, and it's definitely trackpad-related: regular mouse wheels work just fine.

Steps to reproduce

tmux set up with:

set -g mouse on
bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"	
bind -n WheelDownPane select-pane -t= \; send-keys -M

And/or Neovim (or just plain old Vim) with:

set mouse=a

Expected behavior

The above snippets make vim, nvim, and tmux able to be scrolled with the mouse/trackpad on macOS and Linux. They also work in WSL... If I use Xming to run an X server, and use urxvt as my terminal emulator. So, I'd expect that they'd also work for Windows Terminal.

They work in all of the above either alone (e.g. Vim/Neovim not nested inside tmux), or nested (e.g. running Neovim inside tmux).

Actual behavior

For some reason with the Windows Terminal, when I scroll in vim/nvim/tmux (with the editors either nested in tmux or un-nested) they all go absolutely nuts and scroll at like 10x speed, which is kind of unusable. FWIW I'm using a Surface Book and scrolling with my trackpad, if that makes a difference? It looks like it's just sending way more scroll events to the terminal than it should be.

Windows Terminal is otherwise dope and I'd love to be able to replace my janky Xming + urxvt setup for coding on Windows.

Here's a video I captured of the behavior in tmux — I tried to scroll a very small amount, and instead it scrolled 78 rows:

[reissbaker]

FWIW, I dug up a mouse I had lying around and tried scrolling with the mouse wheel. It worked perfectly, so I'm guessing this is an issue with trackpad support for scrolling in the Windows Terminal?

[zadjii-msft]

This seems just like the earlier issue we had where trackpads would scroll the Terminal buffer entirely too fast. I bet we're using the lines to scroll value from the system for scrolling the buffer, but not the VT mouse events we generate.

[reissbaker]

Makes sense. Thanks for the quick response! Looking forward to seeing this one close so I can switch over to using the Terminal.

[reissbaker]

FWIW, this is somewhat worse with WSL2, since WSL2 broke (secure) X server communication from the Linux guest to the Windows host, and so it's unsafe to run Linux-based GUI terminals now.

I switched back to wsltty, but even that has some awkward scrolling bugs when used with trackpads (the beginning of the swipe up is treated as an up arrow, which cycles history in most shells). AFAICT there aren't any terminals on Windows anymore that work with WSL and trackpads.

[DHowett]

Alright, I’m taking this on. Gonna move delta accumulation into the shared mouse input code so both conhost and terminal benefit from it.

[DHowett]

@reissbaker thanks for spurring us into action. 😄

[ghost]

🎉This issue was addressed in #6843, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #6843, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #6843, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

• Release Notes
• Store Download

[reissbaker]

Yesssss thank you! 😁

Edit: tried out the Preview build, works perfectly!

[DHowett]

Happy to hear it. Thanks for letting us know!