Thanks! I'll patch that, try again, and let you know.
I sort of figured that tmux had it's own copy mode input buffer, like
the scrollback buffer. I was surprised that it wasn't something that
was configurable.
I seem to remember this being configurable in screen, but I may be wrong.
Nicholas Marriott wrote:
> Yes we turn off consuming data from the pane while it is in copy mode,
> so it will fill up the tty buffer and the application (if it has not set
> the tty fd to nonblocking) will block.
>
> This is the same as if it was writing to any terminal that doesn't keep
> up... applications which don't want to block really shouldn't assume the
> terminal will always be able to accept data, because it isn't true. It
> is easy to get the same thing in most terminals while selecting/copying
> text or by moving things around in the WM.
>
> However, I don't think we really need to stop reading from the pty. I'm
> not sure what'll happen if we don't but from a quick look it should be
> fine. Please try this and let me know:
>
>
> Index: window-copy.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/tmux/window-copy.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 window-copy.c
> --- window-copy.c 27 Jun 2011 00:04:49 -0000 1.73
> +++ window-copy.c 27 Jun 2011 00:09:54 -0000
> @@ -170,9 +170,6 @@ window_copy_init(struct window_pane *wp)
> data->searchtype = WINDOW_COPY_OFF;
> data->searchstr = NULL;
>
> - if (wp->fd != -1)
> - bufferevent_disable(wp->event, EV_READ|EV_WRITE);
> -
> data->jumptype = WINDOW_COPY_OFF;
> data->jumpchar = '\0';
>
> @@ -232,9 +229,6 @@ void
> window_copy_free(struct window_pane *wp)
> {
> struct window_copy_mode_data *data = wp->modedata;
> -
> - if (wp->fd != -1)
> - bufferevent_enable(wp->event, EV_READ|EV_WRITE);
>
> if (data->searchstr != NULL)
> xfree(data->searchstr);
>
>
> On Sun, Jun 26, 2011 at 04:54:40PM -0700, Jesse Molina wrote:
>>
>> Hello!
>>
>> I have an application which I run in tmux. It has a rudimentary console
>> that takes commands and it gives regular output as well.
>>
>> I recently noticed that if I do a ctrl+b and pgup to look at the
>> scrollback history, the application will stop running after a few
>> moments. Sometimes it takes 30 seconds, sometimes 2 minutes. I get the
>> impression that some buffer is being filled.
>>
>> The application in question does a lot of network activity and
>> everything comes to a complete halt if I do this. If I then press esc
>> twice to break out of copy mode, the application starts running again.
>>
>> What advice do wise tmux users have for me?
>>
>>
>>
>> --
>> # Jesse Molina
>> # Mail = je...@opendreams.net
>> # Page = page-je...@opendreams.net
>> # Cell = 1.602.323.7608
>> # Web = http://www.opendreams.net/jesse/
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> tmux-users mailing list
>> tmux-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tmux-users
--
# Jesse Molina
# Mail = je...@opendreams.net
# Page = page-je...@opendreams.net
# Cell = 1.602.323.7608
# Web = http://www.opendreams.net/jesse/
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
