alternate screen buffer has a bad scrollback experience

[jwforres]

1. Use an application like vim that uses the alternate screen buffer
2. Use the arrow keys or page up / down so that content is added to the alt screen's scrollback buffer
3. Use the scrollbar to view the scrollback content

You will end up seeing duplicated content from the file you were using in vim. This experience is confusing and not consistent with the two typical alt screen scrollback behaviors I have seen in other terminals.

Screenshot from vscode, highlighted sections are the duplicated content caused by the scrollback:

First noticed on 2.8.0 but the issue also exists on master.

Two typical scrollback experiences I have seen for alt screen:

1. The main window contains the alt screen content. The scrollback buffer still contains the scrollback content from the main screen. Example of this is how mac's Terminal behaves.
2. When in the alt screen the scrollback buffer is disabled / set to 0

I think either of these experiences would be less confusing than the current behavior.

[AndrienkoAleksandr]

Seems alt buffer should not use scrollback from the normal buffer.

[AndrienkoAleksandr]

I have experimental branch https://github.com/AndrienkoAleksandr/xterm.js/tree/CHE-5084-2 to improve resize xterm.js mechanism, where is I didn't use scrollback for alt buffer like you said :) but it's unstable yet :), it contains few bugs. I will create pull request when I fix bugs and apply resize terminal tests.

[Tyriar]

This is expected if the program writes more than the dimensions of the terminal. You will notice with git log as an example when you scroll down (down arrow) it will just write new lines at the end of the buffer but when you scroll up (up arrow) it will rewrite the screen. When you use the scrollbar to scroll up things get weird - this is as designed and may be what you're seeing.

[jwforres]

@Tyriar im suggesting the design xterm.js chose is a poor user experience. I can use the same command (e.g. vim) in different terminals and follow the same set of steps and get a better / less confusing experience. Would it help for me to get a screen capture to compare how the mac os Terminal behaves here?

[Tyriar]

@jwforres I can kind of reproduce the same problem in Terminal.app (kind of because I see launching of vim > vim which isn't mean to be on the alt buffer?) but the mouse wheel events are being directed to vim instead of the scrollbar.

Would that solve the problem in your eyes if the mouse wheel was correctly being directed to vim?

[Tyriar]

The mouse wheel in vim problem was already reported in #426

[jwforres]

@Tyriar yeah I had already seen #426 and was also setting mouseEvents: true so that scrolling with the mouse wheel went to the application (here for reference https://github.com/kubernetes-ui/container-terminal/pull/25/files#diff-5f22051b19c04d89d6ea824d4af3a38aR114 ). Scrolling with the mouse wheel actually doesn't cause the issue in this case. The problem is using the arrow keys or page up / down in something like vim will add content to the buffer and cause the scrollbar to appear. If you then manually move the scrollbar (click and drag, not mouse wheel) then you will still see the behavior like what was in the screenshot above.

[jwforres]

@Tyriar would you be open to having an (optionally) separate configuration for scrollback buffer size for the alternate screen buffer?

[Tyriar]

@jwforres the app (vim) would need to be able to set this mode, we can't just assume that all applications are not going to utilize scrollback as some may depend on it.

This is likely an already solved problem. If the behavior is different in Terminal.app then they are likely handling something that vim is telling it that xterm.js is not.

[Tyriar]

Turns out it's actually to spec that the alt buffer should never have a scroll bar:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer

The Alternate Screen Buffer

Xterm maintains two screen buffers. The normal screen buffer allows you
to scroll back to view saved lines of output up to the maximum set by
the saveLines resource. The alternate screen buffer is exactly as large
as the display, contains no additional saved lines. When the alternate
screen buffer is active, you cannot scroll back to view saved lines.
Xterm provides control sequences and menu entries for switching between
the two.

[mofux]

Makes sense. This will also remove a glitch I was seeing when using tmux, where scrolling did not scroll the tmux scrollback but the xterm scrollback, which leads to the tmux bottom bar to disappear.