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