Hi George,<div><br></div><div>Thanks for getting in touch. Definitely open to this in principle. Here's a few questions:</div><div><br></div><div>(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)?</div>
<div><br></div><div>(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.</div>
<div><br></div><div>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.)</div>
<div><br></div><div>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.)</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best regards,</div><div>Keith</div><div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Jul 27, 2013 at 3:26 PM, George Nachman <span dir="ltr"><<a href="mailto:gnachman@llamas.org" target="_blank">gnachman@llamas.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi mosh-devel,<div><br></div><div>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: <a href="https://code.google.com/p/iterm2/wiki/TmuxIntegration" target="_blank">https://code.google.com/p/iterm2/wiki/TmuxIntegration</a>).</div>
<div><br></div><div>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.</div>
<div><br></div><div>The escape code used is DCS 1000p (ESC P1000p), which is based on the ReGIS codes (<a href="http://www.vt100.net/docs/vt3xx-gp/chapter1.html" target="_blank">http://www.vt100.net/docs/vt3xx-gp/chapter1.html</a>). While I don't expect mosh to support ReGIS any time soon, would you consider passing this one escape code through?</div>
<div><br></div><div>Thanks for your consideration,</div><div>George</div></div>
<br>_______________________________________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu" target="_blank">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></blockquote></div><br></div>