> And please show me where are all those unicode aware console
> applications you need that badly to support? Unicode editor for
> example?
There are almost none (I know only one for console, sted, and it is poor).
That does not imply that we should do everything to prevent them do be
easily done in future! There are almost none because there is not enough
Unicode support in curses, libc, kernel and X; e.g. curses even couldn't
be made to do Unicode well because kernel (or whatever implements the
terminal) does not provide a good method for detecting UTF-8 mode or other
charsets. Every application has to do everything itself and the effect
is that none does this perfectly and every has to be taught separately.
There are still some programs which can't easily use 8bit chars
(fortunately not many) and there are many that understand only ISO-8859-1
(almost all Postscript producers). This is because of your style of
thinking - that OS should provide only ASCII and at most some basic 8bit
chars support, and Unicode etc. should be done at a high level. The
effect is that almost nobody cares to implement anything else and when it
implements, it has to do it itself, in a way incompatible with others and
requiring manual configuration of every program (lynx has to be told about
terminal charset, Yudit does its own keyboard handling, Netscape (at least
4.0something) can't use Unicode fonts - every of them does Unicode better
or worse). Many programs should handle multiple charsets including Unicode,
but they do not.
Even some charset translation has to be done in kernel, because it is
needed in filesystems! The basic terminal handling also has to be in
kernel. And how would you do it to allow enhancing it in userspace -
how would you let them use Unicode when they are originally prepared to
use 256 chars only? The reverse would be possible - if the kernel terminal
supported Unicode *only*, the emulation of other charsets could be done
in userspace (probably currently not very easily, as the terminal driver
would have to be run at every login). It would complicate gpm, which would
have to know what an unknown userspace terminal driver expects as input,
and it would leave you with Unicode after init=/bin/bash.
So what do you propose? Remember that the result has to provide a UTF-8
terminal in text mode (or graphics mode which is as fast as text mode,
works on every VGA card, is tunable with something like SVGATextMode, does
not require to start such a huge program as X, works with gpm and provides
scrollback buffer and virtual consoles).
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a21 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/