Nicholas Marriott writes:
> On Sun, Feb 14, 2010 at 01:22:02PM +1100, Trent W. Buck wrote:
>> Having said that, I'm haven't worked out how to make "setw -g
>> remain-on-exit on" only apply when the application returns a non-zero
>> exit status (the "onerror" in Screen's ":zombie kr onerror").
>
>
It can't apply only to errors, although it isn't a bad idea.
On Sun, Feb 14, 2010 at 01:22:02PM +1100, Trent W. Buck wrote:
> Nicholas Marriott wrote:
> > What's the problem? tmux works the same way.
>
> I was really just mentioning ~M~. as a workaround (for the ssh case).
>
> Having said that,
Nicholas Marriott wrote:
> What's the problem? tmux works the same way.
I was really just mentioning ~M~. as a workaround (for the ssh case).
Having said that, I'm haven't worked out how to make "setw -g
remain-on-exit on" only apply when the application returns a non-zero
exit status (the "onerr
Hi
On Fri, Feb 12, 2010 at 07:59:33PM +1100, Trent W. Buck wrote:
> [Going through the list's archives via gmane...]
>
> Using tmux 1.1, I still get this kind of behaviour. The contrived
> example I used was
>
> 1. start tmux
> 2. ^B%
> 3. for i in {1..99}; do dmesg; done
> 4. ^
[Going through the list's archives via gmane...]
Using tmux 1.1, I still get this kind of behaviour. The contrived
example I used was
1. start tmux
2. ^B%
3. for i in {1..99}; do dmesg; done
4. ^Bo (is ignored for a long time)
I'm still using GNU Screen, with a remote screen
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
To reproduce:
Get on a Window machine.
SSH into a Linux machine using Putty.
Run tmux on the remote.
Split the tmux window into two panes (one above the other)
You should have two shell windows now.
Move into lower pane
At the prompt type the following and hit enter: perl -e '$a=0;
while(1) { prin
11 matches
Mail list logo
