alacritty with tmux with mouse=off (falsely?) detects prompt as having a faux scroll

[maximbaz]

Arch Linux, X11, scrollback branch (55ba604)

Use default configuration for zsh, tmux and alacritty.

• Open alacritty.
• Start tmux.
• Generate some output (e.g. run $ tree).

Mouse mode is disabled by default in tmux, but if you want to make sure, press Ctrl+B and type:

set mouse off

Now scroll up and down with the mouse wheel.

Expected: scrollback kicks in.

Actual: alacritty thinks there is a faux scroll and sends arrows up/down, so instead of terminal history being scrolled I see the history of commands being scrolled:

There are workarounds:

• Disable faux scroll in alacritty.yml
• Disable faux scroll in .tmux.conf: set -ga terminal-overrides ',*256color*:smcup@:rmcup@'
• Hold Shift and scroll (@chrisduerr implemented this recently)

The first two workarounds are not very cool, because I want to use faux scroll when it really exists, for example in man. Constantly holding Shift when using tmux is annoying.

But my main issue is really this: why alacritty thinks that there is a faux scroll in prompt? Why it sends arrow keys to the prompt, causing the scroll of my previous commands?

To be fair, I tried in sakura terminal and it does the same.

If this is could not / should not be fixed in alacritty, do you know perhaps a way to disable faux scroll in the prompt without disabling it completely? Something I could put in .zshrc or .tmux.conf?

[chrisduerr]

This is just how faux scrolling works. It works this way in every terminal emulator I've seen. Whenever you are in the alternative scrollback buffer (basically every full-screen terminal application like tmux, htop, vim, ...), faux scrolling is enabled.

It's not possible to detect if faux scrolling is desired or not. The expectation is just that when you're in the alternative screen buffer and the application doesn't take care of mouse events, it might be convenient to provide this "hack".

It's not a terminal escape sequence or an intentional thing. It's just a convenience thing that's mostly seen in VTE terminals which makes using stuff like less/man a bit simpler.

Also please not that using the native alacritty scrollback is not really intended in the alternative screen buffer. According to specification this is an area without any scrollback buffer, so when this works in an application it's kinda against the specification. Just like faux scrolling is unspecified to my knowledge.

[maximbaz]

I see... your explanation makes a lot of sense, thanks!

[chrisabruce]

Is there anything special needed to get shift to work? I get the above behavior with alacritty and tmux, but shift doesn't seem to do anything put prevent the command scrolling.

[chrisduerr]

This is the intended behavior, what else would you expect it to do?

[chrisabruce]

I guess I am misunderstanding the comment above:

Hold Shift and scroll (@chrisduerr implemented this recently)

I guess I read that as that if I hold down shift while scrolling, then it would scroll the scrollback buffer and not the command line. Is that wrong?

[chrisduerr]

There is no scrollback buffer in the alternate screen buffer.

[jesstelford]

For future Googlers, the second workaround (set -ga terminal-overrides ',*256color*:smcup@:rmcup@') has an explanation here: https://superuser.com/a/314620

fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.

The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.

(sorry for the zombie post)