> 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?).
>
Sorry for the delay. The VT terminals completely separate the input
and output methods. For data from the host they use ISO 2022.
However, for input from the keyboard they use a combination a LANGUAGE
and NRC-MODE state to determine what character should be sent to the
host. Under no circumstances does a change in the ISO 2022 state
affect the output to the host generated by keyboard input.
The host application can query the Keyboard Language with the
CSI ? 26 n
sequence. The response
CSI ? 27 ; Pn ; Pst ; Ptyp n
indicates Keyboard Language (Pn); Status (Pst); and Type (Ptyp)
Valid Lanuages are (sorry, I don't have time today to type the entire list)
0 Unknown
1 North American
2 British
...
39 Russian
40 Latin American
Status:
0 Ready
3 No Keyboard
8 Keyboard Busy
Type:
4 LK411
5 PC
The Keyboard Language can be set by the host using
CSI Ps1 ; Ps2 SP }
Where Ps1 is Type:
1,0 DEC layout
2 PC layout
and Ps2 is Language:
0,1,none North American
2 British
...
39 Russian
40 Latin American
I do not believe it is a good idea to tie the keyboard input
processing to the state of the ISO 2022 tables for the host to
terminal direction. You certainly do not want to tie it to the
current values of GL and GR.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL. SSH soon to follow.
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
