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
