confused with mouse sequences. Also set a flag and don't bother checking
for it if we have already seen it (same for DA), and don't check if we
never asked for it.
immediately rather than queuing them (the command can block the queue
which means they were not being seen until it finished which was too
late). Reported by denis@ and solene@, ok solene@.
is changed to on), also add refresh-client -l to ask tmux to use the
same mechanism to get the clipboard from the terminal outside
tmux. GitHub issue 1477.
xterm-keys by default, generates \033[1;3A instead of
\033\033[OA. Unfortunately this confuses vi, which doesn't understand
xterm keys and now sees Escape+Up pressed within escape-time as Escape
followed by A.
The issue doesn't happen in xterm itself because it gets the keys from X
and can distinguish between a genuine M-Up and Escape+Up.
Because xterm can, tmux can too: xterm will give us \033[1;3A (that is,
kUP3) for a real M-Up and \033\033OA for Escape+Up - in fact, we can be
sure any \033 preceding an xterm key is a real Escape key press because
Meta would be part of the xterm key instead of a separate \033.
So change tmux to recognise both sequences as M-Up for its own purposes,
but generate the xterm version of M-Up only if it originally received
the xterm version from the terminal.
This means we will return to sending \033\033OA instead of the xterm key
for terminals that do not support xterm keys themselves, but there is no
practical way around this because they do not allow us to distinguish
between Escape+Up and M-Up. xterm style escape sequences are now the de
facto standard for these keys in any case.
Problem reported by jsing@ and subsequently by Cecile Tonglet in GitHub
issue 907.
supports them (that is, if it advertises itself as a VT420 - probably
just xterm). These are the vertical equivalent of the scroll region and
allow much faster scrolling of panes that do not take up the full width
of the terminal.
poor idea that was fairly quickly replaced by SGR mouse input (which is
now widespread). It is impossible to tell the difference between UTF-8
and non-UTF-8 mouse input; since the mouse-utf8 option was removed tmux
has not handled it correctly in any case; and it is ridiculous to have
three different forms of mouse input.
uint64_t and converting UTF-8 to Unicode on input and the reverse on
output. (This allows key bindings, there are still omissions - the
largest being that the various prompts do not accept UTF-8.)
options for "mouse-this" and "mouse-that", mouse events may be bound as
keys and there is one option "mouse" that turns on mouse support
entirely (set -g mouse on).
See the new MOUSE SUPPORT section of the man page for description of the
key names and new flags (-t= to specify the pane or window under mouse
as a target, and send-keys -M to pass through a mouse event).
The default builtin bindings for the mouse are:
bind -n MouseDown1Pane select-pane -t=; send-keys -M
bind -n MouseDown1Status select-window -t=
bind -n MouseDrag1Pane copy-mode -M
bind -n MouseDrag1Border resize-pane -M
To get the effect of turning mode-mouse off, do:
unbind -n MouseDrag1Pane
unbind -temacs-copy MouseDrag1Pane
The old mouse options are now gone, set-option -q may be used to
suppress warnings if mixing configuration files.
entry:
F13-F24 are S-F1 to S-F12
F25-F36 are C-F1 to C-F12
F37-F48 are C-S-F1 to C-S-F12
F49-F60 are M-F1 to M-F12
and F61-F63 are M-S-F1 to M-S-F3
This should be no difference for applications inside tmux, but means
that any key binding for F13 will need to be replaced by S-F1 and so on.
