Juliusz Chroboczek wrote on 2001-05-25 06:39 UTC:
> ftp://ftp.dcs.ed.ac.uk/pub/jec/programs/luit-0.5.tar.gz
>
> I've made terminal input go through the ISO 2022 state. It is not
> clear that this is the right thing: a real VT100 appears to take all
> terminal input through G0. Should terminal input go through (G0,G2)
> instead of (GL, GR)? In addition, is terminal input allowed to
> generate single shifts, as I currently do?
Interesting question. I guess, the conceptually clean approach would be
to consider terminal input and terminal output as two mostly independent
ISO 2022 communications channels that just attempt to keep their
settings in sync. This would require that whenever you send ISO 2022
commands to the terminal to change G0-G3, that then the terminal will
echo these ISO 2022 commands on the return channel to make the same
changes also effective for this side of the communication. In general,
it seems desirable to keep the G0-G3 settings on input and output
channels in sync, but that is not necessarily the case for the shift
states. Echoing back ISO 2022 sequences over the keyboard channel would
be required in principle to properly avoid race conditions in case
someone is typing while G0-G3 is being changed. On the other hand, I
hope nobody is typing while the encoding is being changed and the vast
majority of applications would probably get confused if they saw G0-G3
change instructions on the keyboard line anyway.
If you receive from the keyboard a character that is not present in the
current G0-G3 setting, then I'd make an option to either send a question
mark (default) or for those users who don't want to loose any
information use "ESC %G UTF-8-sequence ESC %@" for every single
unavailable character.
Can you stack two luit instances on top of each other and do a UTF-8 ->
ISO 2022 -> UTF-8 roundtrip on both the display and the keyboard channel
without any loss of information (except perhaps malformed UTF-8
sequences)?
In any case, getting all this compatible with kterm and VT320
implementation practice is probably far more important than getting it
right "in principle", because people who want to get things right in
principle never would use ISO 2022 in the first place ... ;-)
As far as VT320 ISO 2022 behaviour is concerned, I hope the Kermit folks
will offer their expertise here (Frank? Jeffrey?).
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
