Yeah this only makes a difference without ssh IIRC.
That change is the throttling option but perhaps we need one based on
time rather than buffer size left.
On Tue, Apr 19, 2011 at 05:07:22PM -0700, Robin Lee Powell wrote:
> I do not see much difference, if any; I can try to nail that down if
>
On 2011-04-19, Robin Lee Powell wrote:
> Yeah, ssh in both cases; I know what the network buffering part of
> it looks like. :D
A workaround to this is to this to tell tmux to switch screens, and the
forceably disconnect the ssh connection, and the reconnect. tmux will
have switched screens.
T
I do not see much difference, if any; I can try to nail that down if
it's important. The longer I wait, the worse it gets, so certainly
some sort of buffering seems likely.
I suppose it's possible that tmux is simply pushing so much more
data, or pushing it faster, that the network buffer is an i
Yeah, ssh in both cases; I know what the network buffering part of
it looks like. :D
Let me go grab source and get back to you.
-Robin
On Wed, Apr 20, 2011 at 12:51:06AM +0100, Nicholas Marriott wrote:
> Try this and see if it helps. If you are doing it over ssh it probably
> won't but there is
Try this and see if it helps. If you are doing it over ssh it probably
won't but there isn't much we can do about that because of network
buffering.
Index: server-client.c
===
RCS file: /cvsroot/tmux/tmux/server-client.c,v
retrieving
I have a large terminal (200+ wide/80+ high) running tmux.
Sometimse I have code that dumps large amounts of data, and things
get pretty slow with the redrawing.
That part I'm OK with, but what's bothering me is that in screen, I
could switch windows, and the busy window would update silently
whil
