wheel scrolling doesn't work in tmux / linux

[Canop]

Reported by @willhansen in #153 and confirmed.

[Canop]

Related: https://github.com/crossterm-rs/crossterm/issues/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 https://github.com/tmux/tmux/issues/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 https://github.com/Canop/bacon/commit/ead2e058f0b71b88993716c5e3db760e3f7a7cc9 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 https://github.com/Canop/bacon/issues/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 https://github.com/Canop/bacon/pull/156 enabled on Windows. in this mode both scroll events and click and drag are passed through to the process. this is why https://github.com/Canop/bacon/issues/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 https://github.com/Canop/bacon/issues/174#issuecomment-2290165179; i am happy to make a PR upstream to tmux with that fix. (edit: done https://github.com/tmux/tmux/pull/4076)
• whatever was going on in #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.