Why does tmux fail to “scroll” when entering a command that exceeds one line? (OSX Terminal.app)

Question

When I use tmux and enter a command that exceeds the line, it fails to redraw the previous line. It simply clears the current line and I can't see what I just wrote. It does only redraw the first line.

This also happens when I press up and the last command does not fit the current line (I only see the last line). If I then press up and down again, I can see all lines of the command.

I'm not sure what causes that problem, but it's pretty annoying. Does it have to do something with my prompt? Just in case, here it is:

export PS1="%{$fg[blue]%}%n%{$reset_color%}@%{$fg[green]%}%m %{$fg[yellow]%}%~ %{$reset_color%}% "
export PS2=$_>
($TERM is set to screen)

By the way, I'm using zsh and OSX Termial, but the problem is also there with bash.

Also the problem does not exist with xterm (XQuartz), so i guess it's caused by OSX' Terminal.app.

• Does anyone know a way to fix this anyways?
• Perhaps I could force a redraw somehow?

Just found this old thread on the tmux mailinglist.

I tried different values for $TERM (screen, screen-256colors, xterm, xterm-color, nsterm) but the error persists.

So I guess there is nothing I can do despite switching to another terminal emulator?

Answer 1

This is a bug in Terminal.app which has been noticed by others, e.g., in Any way to fix screen's mishandling of line wrap? (Maybe only Terminal.app)

I can reproduce the effect using bash+tmux, and capturing the text sent to the screen see that tmux is setting the scrolling margins to exclude the last line on the screen before updates that might cause a wrapped line. Meanwhile, bash is writing a long line by writing the part which would fit on the first line, plus two more characters, and then a carriage return and the second line, etc.

The two extra characters should force the line to wrap. But Terminal.app appears to be confused by the switch of scrolling margins along with moving the cursor to the last line of the scrolling region and then writing a long line there. Instead of wrapping, it stays where it is, and the second part of the long line is written on top of the first.

While there is a feature to turn off line-wrapping, most applications assume that it is enabled. In the trace (using script), neither tmux nor bash used it. Unless one of those manipulates the line-wrapping, there's nothing to gain there. tmux, for instance, just assumes the feature and does not even check the terminal description for the am (automargin) capability. It does check the related xenl flag (newline glitch), but removing that from the terminal description would only make things worse.

So... if this bug stops you from using Terminal.app, iTerm2 is a suitable alternative.

Answer 2

I would just download iterm2 and use that.
Most fellow developers I know that use mac just do that.

I think you will find it a more pleasurable environment.

I use iterm2 with tmux and it works great.

http://www.iterm2.com