Higher unicode ranges (e.g. U+A50x until U+A60x) not going through

[2mc]

When working with 'emacs -nw' over ssh all higher unicode characters are displayed correctly (e.g. the VAI block U+A50x until U+A60x), but if connecting via mosh (to the same machine with the same fonts etc.) the characters are either boken up in something else or will not show at all. This does not happen with lower unicode blocks like e.g. polytonic greek (U+1F0x until U+1FFx).

[andersk]

The VAI block was introduced in Unicode 5.1, which is supported by glibc 2.8 and later. mosh only works with characters supported by libc on both the client and the server, so that they can agree on the character’s width. Do you have glibc 2.8 or later on both the client and the server?

[2mc]

Well, I installed mosh 1.2.4 via homebrew on osx 10.7.5, 10.8.5 and via cydia on jailbroken iOS 6.1.2. Whatever combination of server and client I use (even on lookback 127.0.0.1) the behaviour stays the same.

[2mc]

Please let me come back to the hint above. How can I test, if I have a build agaist glibc 2.8? Furthermore, how could I compile mosh with the neccessary glibc 2.8 on a Mac?

[kergoth]

I'm getting problems rendering some unicode characters (though I don't know that its the same ones mentioned in this issue), going from mavericks to a linux box with glibc 2.15. ssh works fine, of course. In my case, it's the line drawing characters used by dvtm (http://www.brain-dump.org/projects/dvtm/). It shows 'q's and 'x's and 'w's instead.

[andersk]

@kergoth, that’s an entirely different issue. You probably lost the NCURSES_NO_UTF8_ACS=1 environment variable that mosh-server sets.

[kergoth]

Ah, thanks!

[2mc]

Hello again! As your eyes came across this older, still unresolved spot.

Please, could anybody tell me how to build mosh on OSX against the necessary glibc 2.8 in order to test higher-unicode support?

[andersk]

I’m not a Mac person (I’m not even sure whether you’re using glibc or some other libc), so someone else will have to help you with that.

[2mc]

Ok. Thank you for the clear answer!
I am no longer waiting here.
I don’t know which c libraries are involved when compiling on a mac either, but I’ll look somewhere else and then come back with hopefully useful infos or even results.

However “Mac persons” reading this, are still very much welcome with their hints.

[mistydemeo]

Just as a note, OS X uses BSD libc, not glibc.

[2mc]

Yes, and meanwhile the ball is played back into the field of mosh -- at least as far as THE mac person from homebrew is concerned. He replied to this very problem that I posted there recently as follows:

"Well, OS X does not use GNU libc ("glibc"), and Homebrew doesn't have any facilities for using an alternative standard library.
Probably there are only two outcomes: either the problem can be fixed in mosh or it can't be made to work at all."

Homebrew/legacy-homebrew#26370

So I would appreciate a lot, if investigations on the mac front to build a version with higher unicode character support could be considered somehow.

[keithw]

Mosh relies on the operating system's libc for Unicode support. Apple unfortunately has been slow to update their C library.

Mosh of course would prefer that Mac OS X get off their duff and update their Unicode tables in the libc they distribute. You can help by filing a Radar bug with Apple. In the meantime, Mosh is investigating shipping its own Unicode tables, but don't expect that to happen anytime soon.

[ghazel]

Which libc functions specifically? ssh appears to work fine, as does a ruby built with rvm and python3 installed with homebrew.

(I've been testing with things like python -c "print '\xf0\x9f\x91\x8d'", etc. which should render as 👍)

[keithw]

wcwidth(). Try this program (fill in your Unicode code point of choice where indicated): http://web.mit.edu/keithw/Public/wcwidthtest.c

[ghazel]

I see. I filed another radar. ( rdar://19339804 )

Looks like zsh includes a replacement https://github.com/johan/zsh/blob/master/Src/compat.c#L633 (based on http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c ).

Would that be a sufficient work-around?