<div class="gmail_extra">On Tue, Apr 24, 2012 at 7:01 AM, Peter Jeremy <span dir="ltr"><<a href="mailto:peterjeremy@acm.org" target="_blank">peterjeremy@acm.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-Apr-23 11:35:25 -0400, Scott Gifford <<a href="mailto:sgifford@suspectclass.com">sgifford@suspectclass.com</a>> wrote:<br>
>Maybe just using the keyboard for scrolling would be OK, but the scrollbar<br>
>UI is pretty friendly and habitual, so it may be hard to move away from.<br>
> Terminal programs also have useful features like search, configurable<br>
>scrollback sizes, etc. that I would miss if they were not also implemented<br>
>in mosh.<br>
><br>
>It's true that screen and tmux have scrolling features built in already,<br>
>but I personally use them only rarely because they are so limited and slow<br>
>to use.<br>
</div></blockquote><div>[ ... ] </div><div><br></div><div>Yes, your points I elided are all very good, and I agree they are what makes scrolling a difficult problem.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are two options for handling scrollback within mosh. The first<br>
is to do it in much the same way as it is in tmux or screen -<br>
scrollback data is tracked within mosh_client & mosh_server and data<br>
that had been optimised out of the transmitted stream is sent on<br>
request when the user scrolls back (via magic character sequences).<br>
This is potentially a RTT slower than a local tmux because missing<br>
data has to be requested from the remote server.<br></blockquote><div><br></div><div>It's not really the speed of data transfer that makes tmux/screen scrolling a hassle, it's the slowness of the interface. I wonder if a history API consisting of terminal escape sequences for up-n-lines, down-n-lines, goto-line-n, and search-history would be enough for a full-fledged GUI terminal to integrate into the history mechanism, including scrollbars?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other option is for mosh to track the full size of the terminal's<br>
scrollback buffer, rather than just the visible screen, and ensure<br>
that any data that would be retained in the scrollback buffer is<br>
transmitted (rather than optimising out data that is not visible).<br>
This would allow you to use the GUI scrollback features but at the<br>
expense of significantly greater memory requirements for both<br>
mosh_client & mosh_server, as well as increased data transfer due<br>
to reduced output optimisation.<br></blockquote><div><br></div><div>That seems simpler than implementing a history API. Without knowing the internal data structures of mosh, my intuition is that the data requirements would be modest. For example, I have a 1000-line scrollback buffer with an 80-character wide terminal, so if historical lines were kept in a circular buffer my configuration would require around 80KB. If the client is online most of that data would be sent anyways; if the client is offline it would be possible to store it on disk until it came back online if server memory consumption were an issue. If I take 1000 lines of find(1) output (a typical case for a scrollback buffer), it is about 60KB of data, and compresses to 8.5KB, so in the case of a client that has been offline for awhile, compression may be able to reduce the data transfer a great deal.</div>
<div><br></div><div>Anyways, I realize that this is all talk unless I'm willing to write some code, and I won't have time for that in the immediate future. Hopefully these thoughts are helpful.</div><div><br></div>
<div>Thanks again to everybody for their hard work on mosh, I've just reconnected to a session after being off the VPN for about 24 hours, and in just a few seconds everything was completely back to normal. Amazing!</div>
<div><br></div><div>-----Scott.</div><div><br></div></div></div>