until the end of the server loop, tmux may have gone through several
internal resizes in between. This can be a problem if the final size is
the same as the initial size (what the application things it currently
is), because the application may choose not to redraw, assuming the
screen state is unchanged, when in fact tmux has thrown away parts of
the screen, assuming the application will redraw them.
To avoid this, do an extra resize if the new size is the same size as
the initial size. This should force the application to redraw when tmux
needs it to, while retaining the benefits of deferring (so we now resize
at most two times instead of at most one - and only two very rarely).
Fixes a problem with break-pane and zoomed panes reported by Michal
Mazurek.
itself hit the "terminal can't keep up" check. To avoid this, record how
much data we send during redraw (we know we will be starting with 0) and
skip the check until it has been flushed. GitHub issue 912.
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.
and not have to wait for an update when they change pane, we allow
commands to run more than once a second if the expanded form
changes. Unfortunately this can mean them being run far too often
(pretty much continually) when multiple clients exist, because some
formats (including #D) will always differ between clients.
To avoid this, give each client its own tree of jobs which means that
the same command will be different instances for each client - similar
to how we have the tag to separate commands for different panes.
GitHub issue 889; test case reported by Paul Johnson.
command. This is used for the session, window and pane for all commands
in the command sequence if there is no -t or -s.
However, using it for all commands in the command sequence means that if
the active pane or current session is changed, subsequent commands still
use the previous state. So make commands which explicitly change the
current state (such as neww and selectp) update it themselves for later
commands. Commands which may invalidate the state (like killp) are
already OK because an invalid state will be ignored.
Also fill in the current state for all key bindings rather than just the
mouse, so that any omissions are easier to spot.
will suppress root key table bindings. So change to always check the
root table if no binding is found in the current table (whether it be
the prefix table from pressing the prefix or the copy mode table from a
pane).
A root key binding can be blocked by binding the key to a command that
does nothing (like send-keys with no arguments).
Problem reported by Thomas Sattler.
bind q select-pane -U \; resize-pane -Z
(There is still some possible weirdness with the way we do current
targets, it should probably be done in a different way at some point.)
reasonable amount (currently width * height * 8 bytes), discard all
output to the terminal and start trying to redraw periodically
instead. Continue with this until the amount of data we are trying to
write falls to a low level again.
This helps to prevent tmux sitting on a huge buffer of data when there
are processes with fast output running inside tmux but the outside
terminal is slow.
A new client_discarded format holds the amount of data that has been
discarded due to this mechanism.
The three variables (when to start this, when to stop, and how often to
redraw) are basically "works for me" at the moment, this is going in to
see how it goes and if it causes problems for anyone else.
with of the terminal scrolls, tmux needs to redraw the entire pane. This
results in a large amount of output data which can cause slow terminals
to struggle, particularly when many lines are scrolled together quickly.
This can be reduced by only redrawing when tmux doesn't hold any
buffered data for the terminal. If a redraw is required and data is
buffered, the redraw is deferred until all that data is consumed (it is
checked after every event loop, a timer is used to ensure this happens
at some point). While a redraw is pending, no additional data will be
written to the terminal.
The redraw still happens, now it is just pushed back if it is possible
it would just add more data on top of a terminal that is already
behind. This both gives the terminal a chance to catch up, and allows
tmux to process more scrolling (that would require additional redraws)
in the meantime.
Helps with a problem reported by Greg Hurrell.
falls back to an alternative if the tty name is not available. This is
clearer than overloading the client ttyname member and allows us to
remove the path stored in the tty struct, it should always be the same
as the client.
jobs, this means that if the same job is used for different windows or
panes (for example in pane-border-format), it will be run separately for
each pane.
main issue is that if we have two panes, A with 1002 and B with 1003, we
need to set 1003 outside tmux in order to get all the mouse events, but
then we need to suppress the ones that pane A doesn't want. This is easy
in SGR mouse mode, because buttons == 3 is only used for movement events
(for other events the trailing m/M marks a release instead), but in
normal mouse mode we can't tell so easily. So for that, look at the
previous event instead - if it is drag+release as well, then the current
event is a movement event.
so too early, before the mouse event was necessarily valid, so could end
up using the pane from the previous mouse event, or the active pane.
It is important that we use the right pane now that different panes can
have different key tables (for copy mode).
Fixes problem reported by Greg Hurrell.
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.
add a link of winlinks to each window and a pointer to the session to
each winlink. Also rewrite the alerts processing to return to the old
behaviour (alert in any window sets the flag on any winlink).
but there is also now a global command queue. Instead of command queues
being dispatched on demand from wherever the command happens to be
added, they are now all dispatched from the top level server
loop. Command queues may now also include callbacks as well as commands,
and items may be inserted after the current command as well as at the end.
This all makes command queues significantly more predictable and easier
to use, and avoids the complex multiple nested command queues used by
source-file, if-shell and friends.
A mass rename of struct cmdq to a better name (cmdq_item probably) is
coming.
support line editing and instead executes a command as soon as a
non-number key is pressed. Add a -N flag to command-prompt for the same
in copy mode. Reported by Theo Buehler.
The vi-copy and emacs-copy mode key tables are gone, and instead copy
mode commands are bound in one of two normal key tables ("copy-mode" or
"copy-mode-vi"). Keys are bound to "send-keys -X copy-mode-command". So:
bind -temacs-copy C-Up scroll-up
bind -temacs-copy -R5 WheelUpPane scroll-up
Becomes:
bind -Tcopy-mode C-Up send -X scroll-up
bind -Tcopy-mode WheelUpPane send -N5 -X scroll-up
This allows the full command parser and command set to be used - for
example, we can use the normal command prompt for searching, jumping,
and so on instead of a custom one:
bind -Tcopy-mode C-r command-prompt -p'search up' "send -X search-backward '%%'"
command-prompt also gets a -1 option to only require on key press, which
is needed for jumping.
The plan is to get rid of mode keys entirely, so more to come eventually.
pane-border-status is set to "top" or "bottom" (rather than "off"),
every pane has a permanent top or bottom border containing the text from
pane-border-format.
Based on a diff sent long ago by Jonathan Slenders, mostly rewritten and
simplified by me.
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.)
around, we can't use file descriptors for the working directory because
we will be unable to pass it to a privileged process to tell it where to
read or write files or spawn children. So move tmux back to using
strings for the current working directory. We try to check it exists
with access() when it is set but ultimately fall back to ~ if it fails
at time of use (or / if that fails too).
