I have seen a problem like this when using multi-byte (UTF-8 encoded) characters in the prompt, but only when tmux’s
utf8 window option is turned off.
To identify such characters look for any “fancy” shapes, special symbols, or accented characters that are outside the ASCII repertoire (i.e. any Unicode codepoint beyond U+007F).
To check whether the
utf8 option is active use this command in a window that is having the problem:
tmux show-option -gw utf8 \; show-option -w utf8
(or at a tmux
: prompt without the leading
tmux and without the backslash)
If it shows two values, then the second one is the active value for that window. The first (or only) value is the global value that will be used if there is no window-local value established.
If you are seeing a different value from the one established by your configuration file, then you probably need to restart your server (or iff the changes made by your configuration file are idempotent, then you can
tmux source ~/.tmux.conf).
The problem arises because (without
utf8 enabled) tmux and your external terminal emulator have a different idea of how many columns are used to display each multibyte character. tmux expects a multibyte character to take up multiple columns (one for each byte), but your external emulator is probably configured to recognize it as a single UTF-8 character and thus will render it in a single column.
The problem is especially visible in a zsh prompt because zsh is careful to track where the cursor is so that is knows when the line will break and what it needs to do to properly redraw the prompt. Unfortunately, the mismatch between (non-
utf8) tmux and the (UTF-8 configured) external emulator causes tmux to report a cursor position that is several columns to the right of the expected position (one extra space for each extra byte in every multibyte character in the prompt).
utf8 in tmux fixes the problem because both tmux and the external emulator will recognize the sequences for each multibyte UTF-8 codepoint as taking up a single column. Reconfiguring your external emulator to use a single-byte encoding would also fix the discrepancy, but at the cost of not being able to properly view UTF-8 encoded data (although such a view does basically show you what tmux is “thinking” when
utf8 is off).