Issues with integrated tmux when resizing terminal emulator

[VorpalBlade]

When resizing the terminal emulator to be bigger than before, lines in history are overwritten by the screen buffer. This does seem tied to the terminal emulator.

• If I use konsole only a single line is lost per event (click-drag-release)
• If I use mate-terminal multiple lines are lost, and this is proportional to how much I resize the window.
• If I use the built in terminal in VS Code it behaves as mate-terminal does.

It is kind of hard to explain, so I have recorded my screen to demonstrate it. I have uploaded it to youtube: https://youtu.be/uLvq8osknAM

[romkatv]

Yes, when you resize your terminal, things can go pretty bad in zsh4humans. Prompt goes crazy, content in the scrollback gets wacky, etc. In theory it might be fixable -- I'm not sure it is -- but it's hard. It's unlikely that I will ever attempt it.

[romkatv]

To expand on this, z4h needs to know what's on the visible part of the TTY. When you increase the height of the terminal window, two things can happen: either the terminal adds new lines at the top so that scrollback becomes visible, or it adds empty lines at the bottom so that the visible part of the screen stays unchanged. z4h doesn't know what the terminal does, so it has to guess. Currently it always assumes the latter -- that empty lines are added at the bottom. If the terminal actually does the former, some lines get lost. I can change z4h so that it assumes that scrollback is added at the top. In this case some lines will be duplicated on terminals that add empty lines at the bottom.

As far as the actual terminal behavior goes:

• Add scrollback lines at the top: xterm, all terminals based on VTE (GNOME Terminal, Mate Terminal, Tilix, etc.), all terminals based on term.js (integrated VS Code terminal, Hyper, etc.).
• Add empty lines at the bottom: Windows Terminal.
• Configurable: Kitty.
• Something weird: Konsole (it tries to add lines at the bottom but apparently has a bug where it first adds one line at the top and then changes its mind and scrolls).

Maybe this should be an option in z4h (all it would do is set history-limit to non-zero value in the tmux config). Maybe I should try to detect what the terminal is doing on resize by querying the cursor position after SIGWINCH. This can be tricky but would be the best solution if it works.

[VorpalBlade]

Given what you said, it seems an option is the best option (pun intended). Then the user could set it as they want. I wouldn't bother trying to support konsole, but I would report it as a bug to KDE. However I don't understand the nuances of terminal emulation, so you would likely be able to explain and demonstrate the issue better than me.

[VorpalBlade]

I poked around a bit, and there are environment variables such as VTE_VERSION and KONSOLE_VERSION. VSCode sets TERM_PROGRAM=vscode but then that is overwritten by the integrated tmux at whatever point that happens at. It is also possible that konsole and the other terminals set TERM_PROGRAM but I didn't check, it gets overwritten by tmux.

[romkatv]

These are unreliable because they don't travel through sudo and ssh. The only reliable way to query the type of the terminal is via \033[>q but that stops at the first layer. It also requires a round-trip.

It's possible to combine a bunch of unreliable heuristics into something that works most of the time. It's work though. I'm sympathetic to your plight but it's hard to be excited about a fix/feature that 1) I personally don't care about 2) few other users do 3) there is no real fix for it, just workarounds.

I can add an option. That's not difficult and it would work just as well as a perfect solution for you.

[VorpalBlade]

Option sounds good yes. As I mostly use VTE terminals. Konsole is the exception on one computer.

[romkatv]

I added a new option:

zstyle ':z4h:' term-vresize 'top'

Once you set this option in zshrc and run z4h update, open a new terminal tab, run seq 1000 and resize the terminal to make it taller. Prompt should stay at the bottom and a part of scrollback that was hidden prior to resizing should now be visible. In other words, additional lines should be added to the terminal at the top.

The default value is bottom. In this case new empty lines get added at the bottom of the terminal so that prompt remains on the same line number.

Let me know how it works for you. If you don't notice any issues, I'll add some heuristics to try to guess the appropriate value if the option isn't set explicitly.

[romkatv]

Closing as kinda-fixed.