Bug#254316: CJK font fails after running slang/ncurses program

[Juliusz Chroboczek <jch@pps.jussieu.fr>]

TD> ...and since it has to be set to a particular value (and because there's
TD> no good method to determine what it was - or isn't there?) you suggest
TD> that the application not use G1 for anything else.

Exactly.  (There is none.)

I suggest that the application use smacs=\E(0, which sets G0 to point
at DEC Special instead of G1.  Now in principle the problem is the
same with G0; but it so turns out that all Unix locales (even EUC-JP)
set G0 to point at US-ASCII, which can be recovered with rmacs=\E(B.

TD> But (now that I'm thinking along those lines), luit knows what the
TD> particular value is, and in principle could have massaged the ^O
TD> into a string that would select BG 2312 back into G1.

^N is a locking shift into G1 mode, and ^O is a return to G0 mode.  In
order to print a DEC Special character, you can either select DEC
Special into G0, or else select DEC Special into G1 and shift into G1
mode.

Now suppose luit has GB-2312 in G1, the application selects DEC
Special into G1, shifts into G1, prints a character, and then shifts
back into G0.  How do I know whether it actually meant to keep DEC
Special in G1 for further usage, or whether it was only kidding?

(Well, I could cheat: I know what the xterm termcap entry is like, and
that's enough information to work that out.  But I'm not volunteering.)

>> the morass of complexity that some mindless jerk who'll be first
>> against the wall when the revolution comes standardised as ISO 2022.

TD> ( google suggests 2022 has many fans ;-)

We'll use a larger wall.

                                        Juliusz