Tomohiro KUBOTA wrote on 2004-03-01 15:17 UTC: > > to the left, not one *cell*. I know that this is not what backspace does > > in some EUC terminal emulators, but I believe a strong case can be made > > A correction. Not *some* EUC terminal emulators, but *every* EUC > terminal emulators.
But remember that UTF-8 is not EUC, and it is not clear to me why UTF-8 terminal emulators need to be compatible with EUC terminal emulators, if they do not even use the same character encoding. The notion of BACKSPACE removing one character is clearly the only practical one if you use a terminal emulator, for example, with proportional fonts. Fact is, that EUC has a very simple way of distinguishing between exactly two glyph widths, which makes such a solution feasible, whereas UTF-8 has not, which forces us to find a proper more general solution, a solution that will later even be very useful for terminals that use proportional fonts. We are still in the process of figuring out, what the best way of extending the very simple traditional terminal semantics is, which came from that of first a mono-spaced typewriter and later a very memory-restricted video terminal, in an age where users expect not just double-width characters, but also combining characters and ligatures. > Kernel will have to handle wcwidth() anyway > - to display doublewidth characters on the console You are now talking about the console driver, which is a very different module from the tty driver. With regard to the console driver, I am somewhat skeptical whether it is a good idea to put any double-width support into it at all. These things are much more easily and better done in user space. The main purpose of the kernel console was to provide an extremely robust but somewhat rudimentary interaction capability for booting, installing and trouble-shooting a system, activities that are usually done in ASCII. Think of it more as of a bootstrap aid rather than as a major infrastructure. It needs to work before even a file system is mounted. For anything more fancyful, you better run a separate user-space terminal emulator on top, which has full access to the file system and libc and can therefore provide much more safely the rich and memory-intensive font technologies that you would like to see, including anti-aliasing and intelligent Kanji input methods. There are already plenty good user-space terminal emulators available. [Standard thin-end-of-the-wedge argument: If you want to have Kanji in the kernel, where would we stop? Why not put Syriac and Freetype into it soon afterwards, too, along with the full X server? Why have a kernel at all if we can compile all libraries and and applications into one big blob? :-] Markus (who likes kernels to be minimalistic) -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
