[mosh-users] Thoughts on scrolling

[Scott Gifford]

On Tue, Apr 24, 2012 at 7:01 AM, Peter Jeremy <peterjeremy at acm.org> wrote:

> On 2012-Apr-23 11:35:25 -0400, Scott Gifford <sgifford at suspectclass.com>
> wrote:
> >Maybe just using the keyboard for scrolling would be OK, but the scrollbar
> >UI is pretty friendly and habitual, so it may be hard to move away from.
> > Terminal programs also have useful features like search, configurable
> >scrollback sizes, etc. that I would miss if they were not also implemented
> >in mosh.
> >
> >It's true that screen and tmux have scrolling features built in already,
> >but I personally use them only rarely because they are so limited and slow
> >to use.
>
[ ... ]

Yes, your points I elided are all very good, and I agree they are what
makes scrolling a difficult problem.

There are two options for handling scrollback within mosh.  The first
> is to do it in much the same way as it is in tmux or screen -
> scrollback data is tracked within mosh_client & mosh_server and data
> that had been optimised out of the transmitted stream is sent on
> request when the user scrolls back (via magic character sequences).
> This is potentially a RTT slower than a local tmux because missing
> data has to be requested from the remote server.
>

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?

The other option is for mosh to track the full size of the terminal's
> scrollback buffer, rather than just the visible screen, and ensure
> that any data that would be retained in the scrollback buffer is
> transmitted (rather than optimising out data that is not visible).
> This would allow you to use the GUI scrollback features but at the
> expense of significantly greater memory requirements for both
> mosh_client & mosh_server, as well as increased data transfer due
> to reduced output optimisation.
>

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.

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.

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!

-----Scott.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-users/attachments/20120424/0f70f1d8/attachment-0001.htm