[mosh-devel] mosh releases

[Keith Winstein]

On Wed, May 27, 2015 at 7:00 AM, John Hood <cgull at glup.org> wrote:

>  (3) When the mosh-client prints a new character to the screen that it's
> never printed before, it then interrogates the terminal to get its current
> column to verify that the terminal emulator's idea of the width is the same
> as what's in the Terminal::Complete object. If yes, it marks it as a
> dependable character where the Terminal::Complete width matches the outer
> termemu's width. Otherwise, it marks it as a problematic character (so that
> it needs to absolutely position whatever comes next). Probably we can
> assume that all the characters in Unicode 3.0 without ambiguous widths are
> handled properly or something.
>
>  What do you think?
>
> I'm a little uncomfortable with querying the terminal on the fly for
> cursor position-- I don't 100% know why.  At least part of it is that there
> is a long-standing issue with terminal input combined with terminal
> reports:  if the user (in Emacs, say) types ESC, pauses (on the normal
> human scale for typing), mosh-client sends the Cursor Position Report
> sequence and the terminal blats out the response, and then the user types
> X...you have a problem.  Also, the client must wait for the response.  But
> how long should it wait?  1, 10, 1000 milliseconds?  You can't and don't
> know.  And what does it do if it never gets the response?
>

Ok, fair enough. Let's just kill step 3. The client does not try to audit
the character widths that the server is telling it. If there's a mismatch
between what the outer termemu thinks is the character width and what the
mosh-server thinks, it's the user's responsibility to update the
wcwidth.txt file on the server. (This would still be a lot better than the
status quo!)

I haven't seriously looked at the prediction code in a while (maybe ever).
> My naive question is, why does input prediction insert its predicted
> characters, instead of overstriking?  I'd think that overstriking and
> letting the server handle redisplaying inserted characters, even if it's
> laggy, is likely to be a better result in general.
>

Well, try it and see what you think. Most of the time I think I am editing
text in insert mode (and going back to fix typos and stuff), and it's nice
to have that handled locally. But I haven't done an A/B test probably since
early 2012.

-Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20150528/ed4db16f/attachment.html