Dear Thomas, dear all,
The xterm terminfo says:
enacs=\E(B\E)0, smacs=^N, rmacs=^O,
In plain terms, it selects DEC Special into G1, and then switches
between ASCII and DEC Special using SO/SI. This has the unfortunate
effect of breaking the ISO 2022 state with luit and kterm.
I have worked around this by pointing GR at G1 in non-EUC locales in
the latest version of luit. Unfortunately, there is nothing that can
be done for EUC locales.
The vt220 entry uses the following instead:
smacs=\E(0$<2>, rmacs=\E(B$<4>,
This only uses G0, and switches between ASCII and DEC Special on the
fly. The advantage is that G1 is untouched, and as long as the
application only uses ASCII in G0, everything will be fine.
Is there any reason why this approach should not be used with XTerm?
If not, could I please ask you to consider changing the terminfo and
termcap definitions in the next version of XTerm and ncurses to use
the VT 220 scheme?
In addition, I would be grateful if you could add the following entry.
This will be useful for users of applications that select anything
else than ASCII into G0:
xterm-nacs|X11 terminal emulator with no alternate character set,
acsc@, enacs@, rmacs@,
Thanks a lot,
Juliusz
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
