Great! If you wanted to try to add local prediction for up- and down-arrow, https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc#L824-L836 would be the place to do it.
I don't think we have that high a probability of successfully predicting these locally very often, though, but maybe in a lowbandwidth mosh it's worth it just to move the cursor so the user can see that they've done something? On Mon, Apr 27, 2015 at 8:44 PM, Robert Redelmeier <red...@sbcglobal.net> wrote: > Success! (Thanks for the tip about debian/control). > > -b lowbandwith has the delays I suggested. --predict=[DEFAULT] > and sightly better --predict=experimental give that neat underlining > that disappears and fixes itself when wrong (like vim k for scroll up). > > Horizontal cursor <- and -> work fine, without delays (or at least > working on the buffer). But vertical scrolling has maddening delays > and slow visual feedback. Hard to correctly position cursor. > > -- Robert > > > On 1657-0700 Tue 21 Apr, Keith Winstein wrote in part: > > Can you give a try to the lowbandwidth branch with the > > --predict=experimental command-line option? You might find that > > to be more to your liking. > > > > We could flush out on certain characters -- that would be reasonable (but > > not currently implemented). > > > > Cheers, > > Keith > > > > On Tue, Apr 21, 2015 at 4:49 PM, Robert Redelmeier <red...@sbcglobal.net > > > > wrote: > > > > > On 0022-0700 Tue 21 Apr, Keith Winstein wrote in part: > > > > Hello Robert, Thanks for your email! > > > > > > And thank you in turn for your prompt and detailed reply. > > > > > > > We do this to a degree, > > > > but with the goal of _reducing_ latency -- please see Figure > > > > 3 of the Mosh paper ( https://mosh.mit.edu/mosh-paper.pdf). > > > > > > Fascinating! This 8ms is far too fast for human input, could > > > it be something like ACK & echo packet combining, or combining > > > from terminal local [cut'n']paste? > > > > > > > With the constants tuned differently, we end up reducing the > > > > packets sent as you suggest. This is in the "lowbandwidth" > > > > branch in the Git repository. > > Cheers, > Keith > > > > > > I had a peek, thanks, but could not see how this would work > > > differently from termios.c_cc(VTIME)=5 beyond ^C handling. I tried > > > this dumb delay, and the added latency on top of a slow connection > > > was very irksome. But I found I could reduce the irritation greatly > > > by forcing the buffer out early when a command char was received. > > > Could the special handling for ^C be expanded to all ^char plus > > > duplicated chars (many pgms use hjkl for cursor movement)? > > > > > > Latency during straight typing is far less annoying unless chars > > > are lost. Of course this system generates lots of false flushes. > > > But who cares? Even `bookkeepers` sent as 4 packets is much better > > > than 11, especially considering the "ACK-echo-ACK" multiplication. > > > > > > > > > > On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier < > red...@sbcglobal.net > > > > > > > > wrote: > > > > > > > > > First, thanks y'all for your work on mosh! > > > > > Second, a suggestion for your consideration (_NOT_ a vile "feature > > > > > request"): > > > > > > > > > > Have you considered allowing send buffers to fill a bit before > > > > > sending? Not sending ASAP, but often sending more than one char > > > > > per packet? Of course this increases latency, but reduces packet > > > > > count _tremendously_ and data usage likewise since the payload is > > > > > tiny compared to overhead (incl ACK).. > > > > > > > > > > Not sure how this would interact with SSP, but I hacked ssh to do > > > > > this 10+ years ago. To minimize the latency when it would most > > > > > annoy, the buffer was released if a command was received or when > > > > > typing stopped for 300-600ms. Commands were considered to be any > > > > > control-char or any duplicated char (likely to be cursor movement). > > > > > > > > > > Of course, latency is sometimes noticeable but that is the price > > > > > of reduced transmission data. Most of the time, I'm typing blind > > > > > anyways -- I'm not going to focus on the screen unless needed. > > > > > Sometimes the reductions were as large as 70%, more often 50%. > > > > > > > > > > -- Robert in Houston > > > > > > > > > > > > > > > _______________________________________________ > > > > > mosh-devel mailing list > > > > > mosh-devel@mit.edu > > > > > http://mailman.mit.edu/mailman/listinfo/mosh-devel > > > > > > > > >
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
