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.
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.
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.
printing cells if it is already at the very end of the line and the
terminal will wrap it to the next line itself, this means terminals
still see it as a wrapped line for the purposes of their own mouse
selection. Reported by millert@.
together instead of handling them one by one. This is significantly
faster. Sequences are terminated when we reach the end of the line, fill
the internal buffer, or a different character is seen by the input
parser (an escape sequence, or UTF-8).
Rather than writing collected sequences out immediately, hold them until
it is necessary (another screen modification, or we consume all
available data). This means we can discard changes that would have no
effect (for example, lines that would just be scrolled off the screen or
cleared). This reduces the total amount of data we write out to the
terminal - not important for fast terminals, but a big help with slow
(like xterm).
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.
