emoji characters do not render on Windows

[brenc]

Similar to #612 I cannot get emoji characters to render when using mosh. Using mosh 1.3.2 via Cygwin on Windows 10 in mintty (server is mosh 1.2.6, glibc 2.24). I can get them to display in mintty in a local shell and on a remote shell using ssh, but I can't get them to display at all when using mosh - they display as spaces or question marks.

I have an Ubuntu VM with mosh 1.2.5 and emoji renders using that when using mosh. I'm curious if this is a limitation with Cygwin or if there is something I can do to fix this. For now, my workaround when dealing with emoji is to just use ssh.

[eminence]

Do you have trouble with all emoji? Or just certain characters? If certain characters, can you give an example?

Are you able to test with the server at the latest version (1.3.2)?

[brenc]

Yep - so I built 1.3.2 and logged in using mosh --server=/path/to/1.32 and it does the same thing. I'm using the EmojiOne site to copy the emoji code and paste it into the terminal. Using mosh it prints a white diamond with a ? in it. It appears that any emoji character causes this (I've tried several).

[tzing]

similar problem +1 - all emoji are not rendered

already the latest server + client
but I'm using OSX builtin Terminal.app, not windows

[lucy]

Can reproduce this issue with mosh 1.3.2 in msys2 connecting to a linux host. Both sides are properly set up for en_US.UTF-8 and issue doesn't appear over ssh. It seems like msys2/cygwin builds of mosh can't handle characters that need more than two bytes to encode in utf-16.

$ printf '\U0001fa79\n'
��
$ printf '\U0001F600\n'
��
$ printf '\U00002764\n'
❤

[lifei]

how's this?

[cool-RR]

Hey guys. I'm also affected by this problem. Claude Code believes it knows the solution, I added it below if it's helpful.

---

The root cause is not in MSYS2's wcwidth() tables (they're correct and include emoji ranges). The problem is architectural:

1. MSYS2 uses 16-bit wchar_t (UTF-16), so emoji like ߔ (U+1F534) are stored as two surrogate values: 0xD83D + 0xDD34

2. mosh iterates wchar_t values individually and calls wcwidth() on each one

3. wcwidth() correctly returns -1 for surrogates (0xD800-0xDFFF) since they're not valid characters on their own

4. MSYS2's wcswidth() already handles this correctly (combines surrogates before measuring), but mosh uses wcwidth()

Where the fix should go: mosh, not MSYS2

The wcwidth() API takes a single value - it can't look ahead for the second half of a surrogate pair. This is working as designed.

The fix needs to be in mosh's terminal.cc and terminaloverlay.cc where it calls wcwidth(ch). Before calling, it should detect high surrogates and combine them:

#if WCHAR_MAX <= 0xFFFF  // UTF-16 system
if (ch >= 0xD800 && ch <= 0xDBFF) {  // high surrogate
    wchar_t ch2 = /* get next wchar_t */;
    if (ch2 >= 0xDC00 && ch2 <= 0xDFFF) {  // low surrogate
        ch = ((ch & 0x3FF) << 10 | (ch2 & 0x3FF)) + 0x10000;
    }
}
#endif
const int chwidth = wcwidth(ch);

Relevant mosh PRs:

• #1271 attempted this fix but was closed (too complex)
• #1289 proposes fish-shell wcwidth (won't help - also expects full code points)

[cool-RR]

@keithw I see my comment above with the proposed solution was hidden, either manually or automatically... I hope it wasn't a problem that I posted it.

[lifei]

may try trzsz/ssh to avoid above issues.