On Wed, May 27, 2015 at 7:00 AM, John Hood <cg...@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
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
