wheel scrolling doesn't work in tmux / linux

[Canop]

Reported by @willhansen in #153 and confirmed.

[Canop]

Related: crossterm-rs/crossterm#401
(bacon uses crossterm for event detection)

[jyn514]

fwiw this works around the issue:

bind-key -n WheelUpPane {
  if-shell -F '#{mouse_any_flag}' {
      send-keys -M
  } {
    if-shell -F '#{alternate_on}' {
      send-keys Up
    } {
      copy-mode -e
    }
  }
}
bind-key -n WheelDownPane {
  if-shell -F '#{mouse_any_flag}' {
      send-keys -M
  } {
      send-keys Down
  }
}

(see also tmux/tmux#3705)

you can duplicate send-keys more times to increase the scroll speed.

note that all of this only has an effect if set mouse on is enabled; otherwise all mouse events are passed through unchanged.

[jyn514]

strangely scrolling works fine in vim and helix. i wonder if crossterm isn't telling the terminal emulator it can accept mouse events (mouse_any_flag). i notice ead2e05 only enables mouse events on windows - do you know why that was done?

[jyn514]

ok yes - if i uncomment those cfgs, mouse scrolling works fine in tmux. the problem from #191 also appears; i suspect it is not actually platform specific and bacon needs to set some config that tells the terminal emulator to handle text selection itself.

[jyn514]

ok, i think i have figured out what's going on.

1. by default, the terminal emulator does not send any mouse events to the active process (i.e. the one with the "controlling terminal"); instead it scrolls up in the history.
2. when the "alternate screen buffer" is active, the terminal emulator turns mouse scroll events into up and down arrow keys: https://stackoverflow.com/a/71373998. this happens even if the process has not requested to be in mouse mode. click + drag is still processed by the terminal emulator. this is the "happy path" and how bacon currently behaves on linux.
3. processes can request to be in mouse mode, which is what fix: 🐛 Fix scroll in terminals on Windows #156 enabled on Windows. in this mode both scroll events and click and drag are passed through to the process. this is why Inconsistent terminal behaviour on windows #191 is broken; the terminal emulator expects the events to be handled by bacon.

there are two independent bugs here, excluding anything bacon does.

• tmux handles case 2 incorrectly, by not translating scroll events into arrow keys. this is what i fixed above in wheel scrolling doesn't work in tmux / linux #174 (comment); i am happy to make a PR upstream to tmux with that fix. (edit: done fix mouse scrolling in alternate mode tmux/tmux#4076)
• whatever was going on in Can't scroll using mouse in a terminal ? #153. something weird is going on, because i tested the following cases with tput smcup, all of which worked correctly (translated mouse scroll events to up arrows):
  • git bash
  • WSL2 in Windows terminal
  • WSL2 in cmd.exe (in windows terminal)

i suspect @Adham-A has some broken environment.

given all that, my suggestion is to revert #156, tell tmux users to use the workaround i posted above, and have Adham debug their environment further - i do not think capturing the mouse is a good tradeoff for bacon since it breaks click+drag for selecting text.

[jyn514]

whatever was going on in #153

oh - i think this is a bug in vscode. running tput smcup in its integrated terminal fails to translate scroll events to up and down keys.