In MacOS screen/tmux cannot scroll though scrollback history with mouse/touchpad

[aaronriekenberg]

In MacOS I am finding using the touchpad to scroll through scrollback history does not work when running in a "screen" session. This works with iTerm2.

1. Working steps not using "screen":

   1. cat a large file to create scrollback history (cat /usr/share/dict/words)
   2. touchpad works to scroll up and down through scrollback history. Same behavior in Ghostty and iTerm2.

2. Not-working steps using "screen":

   1. Run screen session
   2. cat a large file to create scroll back history (cat /usr/share/dict/words)
   3. In Ghostty using touchpad to scroll up and down does NOT work. Looks like touchpad inputs work as arrow key up and down, so this recalls old commands. With iTerm2 touchpad works to scroll up and down through scrollback history.

I have also seen same behavior in remote ssh screen and tmux sessions on linux with Ghostty on MacOS

Happy to try to debug more or provide more details if above is not clear.

For me above is something I do often :)

Thanks!

[andr2k]

The following codes are output to the console while scrolling in docker compose exec ...

up: 67;66;60M65;66;60M65;66;60M
down: 66;54;49M64;54;49M66;54;

[simpleapps-public]

@aaronriekenberg In Iterm2 do you have the "Scroll wheel sends arrow keys when in alternate screen mode" advanced option set to "No"? This allows the terminal to scroll out of the "alt mode" display. It also happens to be my preference for tmux/screen behavior and it prevents me from feeling totally at home in Ghostty.

[aaronriekenberg]

@simpleapps-public You are correct, I do have "Scroll wheel sends arrow keys when in alternate screen mode" in iTerm 2 set to No.

Testing "Scroll wheel sends arrow keys when in alternate screen mode" option in iTerm 2:

1. No = touchpad scrolling scrolls though scroll back history in screen/tmux sessions.
2. Yes = touchpad scrolling works as up/down arrows and recalls old command history in screen/tmux sessions. This is same as Ghostty behavior.

No is the default setting in iTerm2, I was not previously aware this option existed. 😄

Does a similar option exist in Ghostty? This is preventing me at least from using Ghostty at the moment. 😄

Thank you!

[simpleapps-public]

I'm not aware of any Ghostty setting that would enable this. You may be able to configure screen to work a little better by enabling its scrollback mode (try ctrl+a esc). This is similar to tmux's mouse mode afaik.

Regardless Iterm2's behavior (and even Terminal.app with "Scroll alternate screen" disabled) is my preference. I don't like tmux's built-in scrolling for most use-cases, especially when working on remote servers. It's much nicer to just natively scroll back the buffer, even if that can create inconsistent history when switching between tmux windows.

[aaronriekenberg]

I am not a big fan of screen scroll back mode (ctrl a + esc) because it is modal/lost each time I type a command. 😞

tmux is a bit better - in ~/.tmux.conf I put:

set -g mouse on

Will see if I can get used to tmux with above mode. At the moment it still seems a bit slower/more jerky than normal

I put another workaround using less below.

thanks @simpleapps-public 😄

[aaronriekenberg]

One workaround I have found - if I pipe inputs to less then touchpad scrolling works as expected in screen/tmux sessions in Ghostty.

# reattach to previous screen session
screen -r 

# touchpad scrolling works in this command
sudo docker logs some_container 2>&1  | less

With this hack one can even have colored output from jq in less: https://dev.to/sshine/jq-hack-1-colored-less-3fo3

# reattach to previous screen session
screen -r 

# colored jq output and touchpad scrolling work
cat big_log_file.json | jq -C '.' | less  -R

Not perfect but better than nothing. 😄

[faceless2]

Coming from regular macOS Terminal (where this "alternate screen" type of scrolling isn't enabled), and as a semi-regular user of screen(1), this one has absolutely floored me. It makes screen completely unusable.

A workaround for the case I usually have (run screen on remote machine) is to run screen on macOS first, then ssh from within screen, then run screen remotely. This seems to disable the behaviour.

But please, please please - can we have an option to disable this? It's nightmarish behaviour that should never be on by default. iTerm2 users seem to largely agree, see https://stackoverflow.com/questions/36594420/how-can-i-turn-off-scrolling-the-history-in-iterm2, but they have an option to disable it.