[mosh-devel] mosh releases

[John Hood]

On 05/27/2015 03:09 AM, Keith Winstein wrote:
> On Tue, May 26, 2015 at 7:35 AM, john hood <cgull at glup.org 
> <mailto:cgull at glup.org>> wrote:
>
>     One other thing I forgot to mention that I'm thinking about: Unicode
>     and wcwidth-related issues.  I currently think that we *do* want/need
>     to have our own wcwidth(), with support for current Unicode versions.
>      I've posted my thinking to one of the Unicode issues on github.
>
That's at 
<https://github.com/keithw/mosh/issues/234#issuecomment-105519519>, btw.
> My best idea here, to really eliminate the possibility of skew between 
> the mosh-server, mosh-client, and outer terminal emulator, is:
>
> (1) The server contains the canonical width table. This can be a text 
> file that we ship with mosh-server (and update when there are new 
> releases of Unicode) that is read in on mosh-server startup.
This amounts to our own wcwidth(), yes.
> (2) The Terminal::Complete object contains a width table, synchronized 
> from the server to the client, that contains the width of only the 
> characters used so far in the session. If the server uses a character 
> that it's never used before, it adds it to the width table, and this 
> gets synchronized to the client via a new kind of Instruction in a 
> HostMessage.
In general I think having the server report its character width 
information to the client is probably a good idea.  I haven't actually 
tried, but I suspect a character width table is very very compressible.  
If it comes out small enough, then we could just compress and send the 
entire thing at session startup, and wouldn't have to deal with 
incremental updates and synchronization.  As with your suggestion below, 
one way to make it even easier/smaller would be to have the transmitted 
info be a delta from a known base table.
> (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 don't fully understand the issues around ambiguous-width characters 
yet.  But I think those do need to be handled from the start-- from 
mosh-server all the way through to the terminal, so that cursor 
positioning and redraw work.

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?
>
>     What is your idea/concept for killing the input prediction
>     rubberbanding with versioned cells?  I'd like to think
>     smart-pointered-rows can help.  Did you post it anywhere? (email,
>     github)
>
>
> I'm not sure I did. I'm afraid I think it's going to mostly take 
> trial-and-error to nail this -- I don't have any great theoretical 
> ideas anymore.
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.  I'd think a user is likely to retain some memory of text after 
their insertion point, having had to search/recognize it to find the 
insertion point in the first place, so sometimes obscuring that text 
when the server is lagging doesn't seem like a big human-factors issue 
to me.
>
> BTW we could move this conversation to mosh-devel at mit.edu 
> <mailto:mosh-devel at mit.edu> if you are comfortable. I think others 
> might like to see what the current thinking is.
Done.  :)

   --jh

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