<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 27, 2015 at 7:00 AM, John Hood <span dir="ltr"><<a 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">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
</span><span class=""><blockquote 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></span>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?</div></blockquote><div><br></div><div>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!)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>-Keith</div></div></div></div>