Jeffrey,
Thanks a lot for your reply. This makes a lot of sense.
I am going to implement the following scheme. The luit wrapper will
have *two* distinct ISO 2022 states, one for output and one for input.
Both states will be initialised from the current locale; ISO 2022
escape sequences will only change the output state, the input state
will remain fixed.
By default, the keyboard will generate 8-bit codes and never generate
any of SS2, SS3, or SO/SI. There will be command-line flags that will
specify that only 7-bit codes should be generated, that SS2 and SS3 are
allowed in keyboard input, and (in 7-bit mode), that SO/SI are allowed.
I believe that this will allow luit to simulate the behaviour of the
DEC terminals, as well as that of KTerm (which, from a cursory glance
at the sources, would appear to generate EUC-JP input).
I'd be grateful for a note if you disagree with any of the above.
Thanks again,
Juliusz
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
