Re: linux-utf8 terminfo description

[Bruno Haible <haible@ilog.fr>]

Klaus Weide writes:

> Finally, a general observation: deducing the UTF-8 state of the terminal
> environment form the name of the $TERM is an ugly trick...  All neccessary
> information an apllication should need should be in the *contents* of the
> temrinal description, not in its name.

I entirely agree with you. But before deciding something here, let's get
the "big picture".

1. A kernel tty must be informed about UTF-8. The line editing behaviour
   (tab and backspace) depends on it. Actually, so that pressing Tab in
   an xterm with wide font works, the kernel needs to have a full wcwidth
   function in kernel space (1.5 KB of data).

If that goes accepted:

2. telnet and rlogin must be modified to pass the UTF-8 state from one
   machine do the other. telnet already passes the DISPLAY environment
   variable, so this is nothing unsurmountable. But rlogin is a bit harder.
   I introduced "linux-utf8" and "xterm-utf8" terminfos to get this done
   with minimum impact on rlogin, but we can probably get away without it:
   "rlogin" could add the "-utf8" suffix itself, and "rlogind" would then
   remove it and set the remote tty into UTF-8 mode.

I'm not convinced "linux-utf8" and "xterm-utf8" are a good idea, because
they are redundant with LC_CTYPE. If your LC_CTYPE is iso-8859-1 and your
xterm is UTF-8, or vice versa, not screen aware applications (like "cat")
will do the wrong thing.

> The same goes for attempts to get this info from LC_ALL/LC_CTYPE/LANG
> environment variables (Bruno's utf8locale.c).

If nl_langinfo(CODESET) would work on all systems, we wouldn't need code
which peeks at the environment variables.

Bruno
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/