On Mon, Dec 19, 2011 at 11:20:29PM +0000, Nicholas Marriott wrote: > This is actually quite a hard problem.
;( I thought it might be. Steal the code from screen? :D > The issue is that it is difficult on a fast machine to rate limit > vast, continuous amounts of data quickly enough and to a slow > enough rate that tmux can remain responsive, without affecting > interactive programs which need to send a lot of data quickly in > bursts > > If tmux takes too long to start rate limiting, then a whole lot of > stuff is already in the terminal buffers and you have to wait. If > it is too aggressive, you'll see full screen programs pause > halfway through drawing the screen. I would be more than happy to accept a configuration parameter for this purpose! -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
