Actually this doesn't work :-/.
Hold on, more to come...
On Tue, Oct 27, 2009 at 07:34:32PM +, Nicholas Marriott wrote:
> Hi
>
> Please try the diff below.
>
> This implements a simple idea - if a terminal isn't accepting our data (the
> output buffer appears to be filling up), do not acc
Hi
Please try the diff below.
This implements a simple idea - if a terminal isn't accepting our data (the
output buffer appears to be filling up), do not accept any more data from panes
being displayed in that terminal.
This appears to fix the problems with two caveats:
- pane output will be li
Hi Nicholas,
Thanks for the response.
Sorry about the ambiguity wrt VNC. I am referring to running two
xterms in VNC with one of them scrolling a lot, not to running tmux
withing VNC. I mentioned VNC because I am using tmux as a substitute
for VNC. If I run the same perl program in an xterm withi
Changing the way buffering of input works is not trivial because everything
possible has to be consumed before poll is called again, but checking for that
is hard because of partial escape sequences. I'll have to think about it.
On Tue, Oct 27, 2009 at 10:13:01AM +, Nicholas Marriott wrote:
>
Hi
tmux commands and output have to share the same resources and you are spending
all of them on perl output. This applies when running anything over the
network.
tmux does very aggressively buffer so it can seem worse, ie it takes longer to
respond to other output, and of course it continues for
