<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/27/2015 03:09 AM, Keith Winstein
wrote:<br>
</div>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, May 26, 2015 at 7:35 AM, john
hood <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cgull@glup.org" target="_blank">cgull@glup.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">One
other thing I forgot to mention that I'm thinking about:
Unicode<br>
and wcwidth-related issues. I currently think that we
*do* want/need<br>
to have our own wcwidth(), with support for current
Unicode versions.<br>
I've posted my thinking to one of the Unicode issues on
github.<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
That's at
<a class="moz-txt-link-rfc2396E" href="https://github.com/keithw/mosh/issues/234#issuecomment-105519519"><https://github.com/keithw/mosh/issues/234#issuecomment-105519519></a>,
btw.<br>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>My best idea here, to really eliminate the possibility
of skew between the mosh-server, mosh-client, and outer
terminal emulator, is:</div>
<div><br>
</div>
<div>(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.</div>
</div>
</div>
</div>
</blockquote>
This amounts to our own wcwidth(), yes.<br>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>(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.</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>(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.</div>
<div><br>
</div>
<div>What do you think?</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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?<br>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">What is
your idea/concept for killing the input prediction<br>
rubberbanding with versioned cells? I'd like to think<br>
smart-pointered-rows can help. Did you post it anywhere?
(email, github)<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAMzhQmN9FczTMUC3AXJpno=ntpevb1PDDcx4+0G-RsW=jyLG9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>BTW we could move this conversation to <a
moz-do-not-send="true" href="mailto:mosh-devel@mit.edu">mosh-devel@mit.edu</a>
if you are comfortable. I think others might like to see
what the current thinking is.</div>
</div>
</div>
</div>
</blockquote>
Done. :)<br>
<br>
--jh<br>
<br>
</body>
</html>