tmux: occasionally CTRL+B <arrow key> prints character code ([A, [B, [C, or [D) instead of switching panes

3

3

When I try to switch panes in tmux with ctrl+b , tmux sporadically prints the corresponding character code [A, [B, [C, or [D instead of switch panes.

I can do this repeatedly, exactly the same way, 75% the time it will switch properly and the other 25% the time it will print the character code instead.

ctrl+b <up arrow>    prints [A
ctrl+b <down arrow>  prints [B
ctrl+b <right arrow> prints [C
ctrl+b <left arrow>  prints [D

I'm using cygwin connected to Linux Mint. Tmux is running on Linux mint, and the shell I'm using is bash.

Edit: to make this question more search-friendly, I'll add these keywords:

Terminal outputs character codes open bracket A, open bracket B, open bracket C, open bracket D.

Any ideas?

Matthew

Posted 2013-01-21T23:13:27.103

Reputation: 966

What terminal emulator are you using under Cygwin? mintty? – jjlin – 2013-01-22T00:02:55.790

Terminal emulator is mintty with terminal type set to xterm-256color. – Matthew – 2013-01-22T18:07:02.180

Answers

2

It sounds like tmux’s escape-time is set a bit to low for the quality of connection you have between your Cygwin system and the Linux system.

Many terminals generate the three byte sequence ESC [ B for the down-arrow key. The escape-time setting tells tmux how long it should wait for a complete sequence after receiving the ESC; if time runs out without receiving a complete sequence, then tmux will treat the individual bytes as individual keystrokes (treating C-b ESC as an unbound tmux key, and passing [B to the active pane’s tty).

So, either you have escape-time set to a very low value (which probably works OK when you access tmux over strictly local connections), or the connection between the two machines sometimes ends up lagging just a bit longer than your escape-time value. You can query the current value with the command tmux show-options -s | grep escape-time.

The default is 500 milliseconds; this should work OK in most situations, but might be too short for marginal connections. You might try raising the value of escape-time:

set-option -s escape-time 1000

You can put this in your ~/.tmux.conf file, run it as a tmux command in a shell inside a tmux session, or type it directly at tmux prompt (opened with C-b :). Note: Changes made in ~/.tmux.conf will not take effect until you re-source the file, or restart your tmux server.

Chris Johnsen

Posted 2013-01-21T23:13:27.103

Reputation: 31 786

+1 for awesome explanation, unfortunately it did not fix the problem. The problem appears to be worse after increasing escape-time :( I should note that the arrow keys do act similarly strangely when attempting to navigate the tmux command line (ctrl+b :). Pressing left to move the cursor on a partially-completed tmux command sometimes erases characters instead of moving the cursor, and I need to press 'i' to be able to type again as if it has vi key bindings and escape was pressed. You're probably right about it being a slow connection problem, but higher escape-times makes it worse. – Matthew – 2013-01-22T19:31:27.390

Well, that behavior at your tmux command-line definitely sounds like a delayed escape sequence problem: the ESC takes you out of insert mode, the [ is ignored (it is not bound in the vi-edit table), and the D is the delete-end-of-line command. I would not have expected a high escape-time to worsen the interrupted-escape-sequence problem; though, it would make vi-style bindings inconvenient—you would always need to wait for escape-time to elapse after pressing the ESC key (i.e. to exit insert mode), and before starting to type normal-mode commands (e.g. b to move back a word). – Chris Johnsen – 2013-01-22T21:06:53.173

Why would this only happen under tmux and not at all when just in bash or a gnu screen session? – Matthew – 2013-01-22T22:07:04.690

Also, it only occurs when interpreted by tmux (after ctrl+b or while on tmux :command line); I can press the arrow keys repeatedly at the terminal in a tmux window with no problems (bash prompt in tmux session). – Matthew – 2013-01-22T22:24:43.653

1Assume the terminal wants to send the three byte sequence ESC [ D, but it pauses after the first byte. If this occurs after your Prefix, the leading ESC is “eaten” as a bindable key combination (Prefix ESC). In vi-style command line editing mode it is “eaten” as the vi return-to-normal-mode key. When you are typing at a tty (e.g. bash in tmux), the ESC is never “eaten”, it it just sent on to the underlying tty as a “separate” key; if the listening process (bash) is not as picky about Escape vs. start-of-sequence, then it will simply wait for the [D and treat it as a left arrow. – Chris Johnsen – 2013-01-23T03:31:00.993

1

I'm having this problem as well; it's definitely specific to the arrow keys (and probably cygwin) For the time being I decided to just unbind the arrow keys and move the select-pane commands elsewhere, and the new key bindings work flawlessly. Not a very satisfying solution though. I'd love to hear if anyone figures out what is going on.

Julia

Posted 2013-01-21T23:13:27.103

Reputation: 11

Asked: 2013-01-21T23:13:27.103

Viewed: 1 453 times

Active: 2013-07-05T18:43:47.723