[mosh-devel] Tmux integration escape code

[Keith Winstein]

Hi George,

Thanks for getting in touch. Definitely open to this in principle. Here's a
few questions:

(1) Is there a way for mosh-client to tell if the host terminal supports
these device control strings? (E.g. a capability in terminfo? An
environment variable you set?) Alternately, have you tested / are you
pretty sure that nothing bad will happen if we pass these along to the
popular terminal emulators that aren't iTerm2 (e.g., iTerm1, Terminal.app,
xterm, VTE, Konsole, urxvt, PuTTY, screen, tmux)?

(2) Mosh works by representing the state of the terminal at the server and
at the client, and synchronizing the states by sending "diffs" between the
state the server thinks the client has and the state the server wants it to
have. We like for the "diffs" between any pair of states (e.g. state #4 and
state #3,927) to be bounded in size, so that we can quickly resynchronize
the client's terminal if it comes back to the network after a long time
away.

Right now I don't think there's anything an application can do to make the
diff grow without bound -- we only store a certain number of combining
characters per cell on the screen, we compress repeated "rendition" changes
down to the minimum diff necessary, etc. (E.g. if the application turns on
and off "bold" on a character 50,000 times, we compress that down into just
one flip if necessary.)

So my preference would be not to pass these device control strings through
literally, because then we'd have to queue them up and have some sort of
flow control to make sure we don't end up with 90 megabytes of pending
updates from a misbehaving app. (Timo Rinne has done a huge amount of work
to support ssh-agent forwarding, which presents the same issues for us, and
before we make a protocol change to support flow-controlled octet
sequences, I want to make sure it's at the right layer.)

If it's possible for us to parse these updates and represent "the state"
that the client is supposed to have as part of our Terminal::Framebuffer
object (like everything else), that would be way better. Is the protocol
documented somewhere? Is somebody from iTerm2 willing to do this and submit
a pull request along these lines?

By contrast, if you really do need just a reliable flow-controlled
octet-stream, I think you'll have to wait until we decide where in the
protocol stack we want that to go and we commit to a protocol change we're
willing to live with going forward.

Best regards,
Keith

On Sat, Jul 27, 2013 at 3:26 PM, George Nachman <gnachman at llamas.org> wrote:

> Hi mosh-devel,
>
> I'm the maintainer for iTerm2, a terminal emulator for Mac OS. About a
> year ago we added a feature to support a deep integration with tmux
> (details here: https://code.google.com/p/iterm2/wiki/TmuxIntegration).
>
> This integration works by passing messages between the terminal emulator
> and the tmux client using a custom protocol. While it works over ssh, it
> fails on mosh because mosh doesn't pass through the escape code that
> signals the terminal emulator to begin speaking the tmux protocol.
>
> The escape code used is DCS 1000p (ESC P1000p), which is based on the
> ReGIS codes (http://www.vt100.net/docs/vt3xx-gp/chapter1.html). While I
> don't expect mosh to support ReGIS any time soon, would you consider
> passing this one escape code through?
>
> Thanks for your consideration,
> George
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130727/2bb4ccfb/attachment.html