Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Resizing tmux pane doesn't update terminfo #2005

Closed
jason0x43 opened this issue Dec 5, 2019 · 9 comments
Closed

Resizing tmux pane doesn't update terminfo #2005

jason0x43 opened this issue Dec 5, 2019 · 9 comments

Comments

@jason0x43
Copy link

Issue description

Resizing a tmux pane doesn't update the terminfo within the pane -- tput will continue to report the original number of lines and columns after a pane is resized. Sometimes it will update after one resize, but not more than that. Detaching and reattaching to a session will update the terminfo.

To reproduce:

  1. Start a tmux session
  2. Split the window horizontally
  3. Note the number of columns reported by tput cols
  4. Resize the pane
  5. Check tput cols again
  6. Repeat 4 and 5. Note that the column count doesn't update.
  7. Detach and reattach. Note that tput cols has been updated.

Required information

Please provide the following information:

  • tmux version (tmux -V).
    • 3.0a
  • Platform (uname -sp).
    • Darwin i386
  • $TERM inside and outside of tmux (echo $TERM).
    • Inside: tmux-256color
    • Outside: xterm-kitty
  • Logs from tmux (tmux kill-server; tmux -vv new).
@nicm
Copy link
Member

nicm commented Dec 5, 2019 •
edited

tmux doesn't have to do anything other than what it does (TIOCSWINSZ), anything else would be up to the shell.

Does stty -a show the right size? Does eval $(resize) fix tput?

@mckellyln
Copy link

If I resize a pane I do see my $COLUMNS and tput cols change values accordingly. But I'm on zsh in terminator.

@jason0x43
Copy link
Author

stty -a shows the same value as tput cols (the incorrect value).

I'm on a Mac, so no resize (and I'm not sure what the Mac equivalent would be).

anything else would be up to the shell.

Hmmm...is the shell involved with tput or terminfo? In any case, why would detaching and re-attaching from a running session cause the line and column counts to update to the proper values?

@nicm
Copy link
Member

nicm commented Dec 5, 2019

Does "tmux lsp" show the right size?

Does this still happen with tmux master? There was some problem about not resizing if there was output.

@jason0x43
Copy link
Author

jason0x43 commented Dec 5, 2019 •
edited

tmux lsp works. Tmux seems to be aware of its own size; tmux lsp always shows the correct pane size. The issue is that at least some apps running within the pane don't know when the pane size has changed.

I haven't tried master yet.

Hmmm...some apps obviously know what the proper pane size is (fullscreen apps like vim). However, other things, like zsh (which updates the COLUMNS env var when the window size changes) and node (which can report columns as process.stdout.columns), do not. Both of these apps do detect window size changes when running directly in a terminal window (as opposed to in a tmux pane).

@jason0x43
Copy link
Author

Ok, so I killed my active tmux server and started a new one, and now it appears to be behaving properly, at least for a simple case with one window and a couple of panes.

@jason0x43
Copy link
Author

I restored a resurrect-saved session, and it's still working. Interestingly, it's not 100% -- every once in a while after I resize a pane, the shell won't notice, but usually it does.

@nicm
Copy link
Member

nicm commented Dec 6, 2019

Try master please and see if you still have the problem.

@nicm nicm closed this as completed Dec 9, 2019
imiric pushed a commit to grafana/k6 that referenced this issue Feb 14, 2020
Add responsive progress bars
7dc9a18 
Progress bars will now dynamically resize depending on terminal window
width, being replaced with percentages if "squished" too far.

It works best on *nix platforms because of SIGWINCH, while on Windows
retrieving the size is required before each render iteration, and isn't
as responsive.

Terminal multiplexers are a bigger issue: tmux seems to buffer
SIGWINCH/terminfo and is plain broken on versions including the current
latest stable (3.0a) (see issue #2005[1]). This was fixed on `master`,
but is yet to be released, and even with the fix the experience is far
from ideal (lags quite a bit, no continuous resize). GNU screen also has
some rendering issues I haven't looked too much into yet.

Untested on macOS terminals, but I expect it to work as well as on Linux.

Terminals tested:
- Linux: st, urxvt, xterm
- Windows: cmd.exe and PowerShell standalone, and both inside the new
  Windows Terminal[2] app. Resizing works fine in all cases, though
  isn't as responsive as on Linux.

Part of #1279

[1]: tmux/tmux#2005
[2]: https://github.com/microsoft/terminal
imiric pushed a commit to grafana/k6 that referenced this issue Feb 17, 2020
Add responsive progress bars
53819f5 
Progress bars will now dynamically resize depending on terminal window
width, being replaced with percentages if "squished" too far.

It works best on *nix platforms because of SIGWINCH, while on Windows
retrieving the size is required before each render iteration, and isn't
as responsive.

Terminal multiplexers are a bigger issue: tmux seems to buffer
SIGWINCH/terminfo and is plain broken on versions including the current
latest stable (3.0a) (see issue #2005[1]). This was fixed on `master`,
but is yet to be released, and even with the fix the experience is far
from ideal (lags quite a bit, no continuous resize). GNU screen also has
some rendering issues I haven't looked too much into yet.

Untested on macOS terminals, but I expect it to work as well as on Linux.

Terminals tested:
- Linux: st, urxvt, xterm
- Windows: cmd.exe and PowerShell standalone, and both inside the new
  Windows Terminal[2] app. Resizing works fine in all cases, though
  isn't as responsive as on Linux.

Part of #1279

[1]: tmux/tmux#2005
[2]: https://github.com/microsoft/terminal
@lock
Copy link

lock bot commented Mar 11, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nicm @jason0x43 @mckellyln