Incorrect cursor position

[caiges]

Using the latest version of Mosh Chrome extension:

The cursor should be one character forward.

[rpwoodbu]

This will almost certainly be either an hterm (terminal emulator) bug or a fundamental Mosh bug. I'm betting it is hterm, because I also see that the cursor doesn't line up with the character; part of the "y" is below the cursor. You might try a different font and see if that helps.

Can you reproduce this in the Secure Shell app using the same terminal font?

[rpwoodbu]

Oh, also, try the "Mosh (dev)" app, which has a newer hterm.

[caiges]

I tried a different font and the dev app just now and got the same result.

[caiges]

I did try a regular SSH session using the same font and it worked fine.

[rpwoodbu]

Hmm, well, I've never seen or otherwise heard of this problem, and don't know how to reproduce it. Can you think of anything that would be special to your setup that could account for this?

[caiges]

I tried this on my Chromebook as well and get the same result.

[rpwoodbu]

OK, my guess at this point is that the prompt is creating confusion. I'll bet that arrow is throwing off some assumption about fixed-width spacing. Can you copy-paste your prompt into this issue verbatim so that I might know what codepoints you're using?

[caiges]

You are correct. Changing my prompt config solves this issue. If there were GitHub gold, I'd send some your way. Thanks!

[rpwoodbu]

Glad to be able to help! I'd still like to know exactly what codepoint you're using. The fact that you can't reproduce this with the Secure Shell app (that is what you meant by "regular SSH session", right?) is peculiar to me, and I'd like to understand that better.

[caiges]

I'm using oh-my-zsh with the default theme "robbyrussell". You're also correct, I did not experience the issue with a regular SSH session. How can I help?

[rpwoodbu]

It would be helpful if you could simply copy/paste the prompt from the Mosh for Chrome terminal window into this GitHub issue, so that I can easily see the codepoints in question.

It would also be helpful if you could clarify what you mean by "regular SSH session". Did you use the Secure Shell Chrome app, or did you run ssh from an xterm, or did you run ssh from an Gnome Terminal, or did you use PuTTY, or what?

I'm specifically curious about the behavior using the Secure Shell Chrome app, as it also uses the same hterm terminal emulator. But if I just have your copy/pasted prompt, I should be able to test this on my own.

[cgull]

I got curious...

With upstream Mosh and OS X Iterm2 and oh-my-zsh with that theme, I get this for a prompt:

➜ ~

That first character is U+279C, which is a Neutral East Asian Width character. That means that terminal emulators (including hterm and mosh) choose whether to interpret/render it as a wide or narrow character, so Asian users can have it as a wide character, and Latin-language users can have it as a narrow character. In @caiges's case, there is disagreement somewhere between mosh-server, the mosh-client code used in MfC, and hterm.

In iTerm2, that character is a wide character; in MfC devel on MacOS Chrome, it is a narrow character. @caiges's screenshot shows it as a wide character, I don't know how that happens. @caiges, which platform are you using MfC on?

Mosh (and by extension MfC) really need to handle Unicode variation better, see mobile-shell/mosh#234 for discussion on this lovely problem. Until then I suggest using an oh-my-zsh theme that avoids newer Unicode characters, and characters with ambiguous width.

[vapier]

i don't think the east asian categories are relevant here. hterm's wcwidth implementation treats all neutral chars as width of 1 all the time. the only chars that can switch between 1 and 2 are the ambiguous ones, and hterm defaults to treating those as 1 (and provides the east-asian-ambiguous-as-two-column setting to users).

i think in this case the issue is the font selection. ➜ renders fine using the default fonts (takes up one column). if you're using a different font which renders it wider, then it will mess things up. powerline fonts are known to take liberties with their glyphs.

handling this dynamically is https://crbug.com/737454. i've got a poc that works, but i need to sort out Unicode grapheme splitting first, and make sure performance doesn't tank.

[rpwoodbu]

Thanks, @vapier. As we have an upstream bug to follow, I'm going to close this issue. Please re-open if this gets fixed upstream and released, and I can do a new build.

[cellcoresystems]

I tried a different font and the dev app just now and got the same result.

you where close but not too close:

I also had al ot of trouble to set up powerline on iTerm2 and also oh-my-zsh and just recently bought a Chromebook and I had the same issue like you.

SOLUTION:
Use the right fonts -> https://github.com/wernight/powerline-web-fonts
No Problem with hterm or iTerm or any other terminal emulator.
use one of those fonts with zsh and you will be happy :o)

[samos123]

I had to change to a different oh-my-zsh theme. I changed to jaischeema and cursor is back to normal. Bash was also working fine.