<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 20, 2014 at 2:00 PM, Vincent Lefevre <span dir="ltr"><<a href="mailto:vincent-mosh@vinc17.net" target="_blank">vincent-mosh@vinc17.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">No, xterm supports the alternate character set, so that since mosh<br>
</div>
declares to emulate xterm by setting TERM=xterm, it must support<br>
ACS (possibly in an optional way, for people who don't like ACS<br>
and don't intend to use it).</blockquote><div><br></div><div>Hello Vincent,</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I *never* get stuck in hieroglyphs with any terminal. So, this is<br>
pointless.</blockquote><div><br></div><div>You will if you run something like: echo -e "\033(0"</div><div><br></div><div>(Or if you abort a program when it was in the middle of writing in the ACS.)</div><div><br>
</div><div>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.</div>
<div><br></div><div>I hope this explains our thinking.</div><div><br></div><div>Best regards,</div><div>Keith</div></div></div></div>