[mosh-users] Alternate character set support (line grpahics) with terminfo

Keith Winstein keithw at MIT.EDU
Thu Mar 20 09:21:47 EDT 2014


On Thu, Mar 20, 2014 at 2:00 PM, Vincent Lefevre <vincent-mosh at vinc17.net>wrote:

> No, xterm supports the alternate character set, so that since mosh
>  declares to emulate xterm by setting TERM=xterm, it must support
> ACS (possibly in an optional way, for people who don't like ACS
> and don't intend to use it).


Hello Vincent,

Unfortunately, terminfo has not been updated to support the difference
between byte-based and UTF-8-based terminals. An ANSI terminal whose state
machine operates on bytes is fundamentally different from an ANSI terminal
whose state machine operates on Unicode (ISO 10646) scalar values after
decoding UTF-8, but there is no way to indicate this difference in
terminfo. Instead, we indicate this with the locale-related environment
variables, which causes its own set of problems.

Some terminal authorities (including the authors of PuTTY, the Linux
Unicode/UTF-8 FAQ, and Mosh) take the position that an ISO 10646 terminal
(i.e. a Unicode one) should NOT support ISO 2022 escape sequences -- the
"alternate character set" you're talking about -- because all of those
coded characters can now be accessed directly without locking shifts.
Markus Kuhn explains why in the FAQ. We think applications are given fair
warning of this by the C locale system -- if you run nl_langinfo( CODESET )
in the implementation-defined locale, you will get "UTF-8". That means (in
our view) that ISO 2022 is not allowed.

Otherwise (including the authors of xterm and VTE and Terminal.app) took
the opposite position -- that the terminal should decode UTF-8, interpret
the result as ISO 10646 code positions, but should also respect ISO 2022
locking shifts. These authors believe that a CODESET of UTF-8 also
implicitly includes ISO 2022 shift sequences.

Mosh has chosen to go with the Linux Unicode FAQ and PuTTY on this one --
we think locking shifts are bad and that ISO 10646 is better than ISO 2022.
If you have an application that speaks ISO 2022, you can certainly run an
ISO 2022 interpreter in front of Mosh yourself. For example, luit or screen.

I *never* get stuck in hieroglyphs with any terminal. So, this is
> pointless.


You will if you run something like: echo -e "\033(0"

(Or if you abort a program when it was in the middle of writing in the ACS.)

In theory I think we are willing to look at a pull request that makes this
an option, and this functionality could be a server-only change. But I will
be up-front that I am pretty skeptical we need to put this into Mosh, given
that this has been our behavior for two years, the number of complaints
we've gotten has been very low, the benefit of avoiding locking shifts is
clear, and affected users can fix the problem today by running luit or
screen.

I hope this explains our thinking.

Best regards,
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-users/attachments/20140320/869ff7e0/attachment-0001.htm


More information about the mosh-users mailing list