Terminal: Vim/Neovim/tmux scroll way too fast with trackpads

Created on 25 May 2020 · 11Comments · Source: microsoft/terminal

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:

ezgif com-video-to-gif

Area-Input Area-TerminalControl Help Wanted Issue-Bug Priority-3 Product-Terminal Resolution-Fix-Committed

Source

reissbaker

All 11 comments

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?

reissbaker on 25 May 2020

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.

zadjii-msft on 26 May 2020

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

reissbaker on 27 May 2020

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.

reissbaker on 8 Jul 2020

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