> Well, we need to support multiple charsets -- at least different
> versions of ISO 8859, as well as KOI-8 and the like -- as soon as
> possible. 2022 seems to be the standard of choice, and I think the VT
> terminal can easily be adapted to be 2022 compliant.
Do we really need such a mess inside kernel, where all these can be
implemented in userspace if the console is physically UTF-8?
Unicode is obviously easier to handle when programs really want to support
multiple alphabets at once, because strings are stateless and because it's
much simpler. One character, one number; can be several bytes in UTF-8,
but it's always the same. No more need of switching charsets.
I can't imagine ISO-2022 in filenames, on web pages, in keyboard maps,
in regexps etc. UTF-8 is already getting there.
What IMHO needs to be done is to allow programs to easily support Unicode.
That is, userspace libraries helping with translations between various
charsets including Unicode and with handling multibyte strings, UTF-8-ized
ncurses / slang / etc. and UTF-8-ized terminals.
Linux console is almost UTF-8. "Almost" because there is no easy way for
querying whether it is in UTF-8 mode or not, or whether the terminal
supports UTF-8 at all and how to switch it on when it does. I don't see
a good way for an interface for this, however: escape sequences are
practically unusable because they require to flush stdin; ioctls don't
get through telnet / xterm / screen. But this is the only missing element.
I vote against complicating the whole thing by adding full ISO-2022
support. UTF-8 is almost done, is *much* simpler and AFAIK gives nothing
less than ISO-2022.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/