Store sessions in an RB tree by name rather than a list, this is tidier
and allows them to easily be shown sorted in various lists
(list-sessions/choose-sessions).
Keep a session index which is used in a couple of places internally but
make it an ever-increasing number rather than filling in gaps with new
sessions.
and allows them to easily be shown sorted in various lists
(list-sessions/choose-sessions).
Keep a session index which is used in a couple of places internally but
make it an ever-increasing number rather than filling in gaps with new
sessions.
Change the way backoff works. Instead of stopping reading from the pty
when the client tty backs up too much, just stop updating the tty and
only update the internal screen. Then when the tty recovers, force a
redraw.
This prevents a dodgy client from causing other clients to go into
backoff while still allowing tmux to be responsive (locally) when seeing
lots of output.
when the client tty backs up too much, just stop updating the tty and
only update the internal screen. Then when the tty recovers, force a
redraw.
This prevents a dodgy client from causing other clients to go into
backoff while still allowing tmux to be responsive (locally) when seeing
lots of output.
Don't return if in the current window since we may want to report a bell
(if bell-action any/current), just clear the flag so the status line
doesn't show the bell.
copy mode uses the real screen as backing and if it is updated while copying,
strange things can happen. So, freeze reading from the pty while in copy mode.
Massive spaces->tabs and trailing whitespace cleanup, hopefully for the last
time now I've configured emacs to make them displayed in really annoying
colours...
Convert the window pane (pty master side) fd over to use a bufferevent.
The evbuffer API is very similar to the existing tmux buffer API so this was
remarkably painless. Not many possible ways to do it, I suppose.
Initial changes to move tmux to libevent.
This moves the client-side loops are pretty much fully over to event-based only
(tmux.c and client.c) but server-side (server.c and friends) treats libevent as
a sort of clever poll, waking up after every event to run various things.
Moving the server stuff over to bufferevents and timers and so on will come
later.
This moves the client-side loops are pretty much fully over to event-based only
(tmux.c and client.c) but server-side (server.c and friends) treats libevent as
a sort of clever poll, waking up after every event to run various things.
Moving the server stuff over to bufferevents and timers and so on will come
later.
If any client currently displaying a window pane has more than 1 KB of output
buffered, don't accept any further data from the process running in the pane.
This makes tmux much more responsive when flooded with output, although other
buffers can still have an impact when running remotely.
Prompted by a query from Ranganathan Sankaralingam.
