On Tue, Sep 10, 2002 at 07:53:12PM +0200, Jochen Hein wrote: > > I'm running in console mode most of the time, so it is rather useful > for me. So this is what I found: > > - UTF-8 works pretty well, as long as the applications support it. > mutt, emacs, bash, and elinks are some of the programs I use. So > from that point of view, it is very useful for me. Yeah!
As already said, it is just a limited subset of unicode > > - Cut&Paste: This workes for characters in ASCII, but not for > e.g. german umlauts. There has been a patch for 2.3.12 > (linux-2.3.12-console.diff as referenced in the Howto). I've > rediffed it for 2.4.19, so if anybody has a need for that -> send > mail. I have a need :-) > Is there any effort in getting something like that into the > current kernels? from following discussions on lkml, is seems that Linus is not interested in unicode and console much => all the efforts have died when patches grew old. > > - Far more interesting is dead keys and (really useful) Compose for > Unicode. There seems to be the unicode_dead_keys_linux-2.4.9.patch, > but if I read it correctly it changes the Kernel ABI > (linux/include/linux/kd.h). Yes. It seemed to be the easier way, and you could not have compose keys for utf-8 mode without modifying the ABI. > After that patch, loadkey should be > recompiled, right? Yes. The right way (with minimal changes to kernel) would be to go through UTF-8 mode completely, with I/O translation in other (8 bit) modes. This way, keymaps could be written in UTF-8 regardless of used mode (sort of what .psf fonts do) The even more right way would be to rewrite console support in kernel from scratch. > > As far as I can see, I can solve all my issues with applying these > patches. But, to keep the number of patches applied locally down, I'd > like to see something like that integrated into the mainline. Or > perhaps a Debian Package kernel-patch-unicode. So has anybody other > issues or solutions? Is anybody pushing UTF-8 patches to mainline? Everyone is just waiting for new linuxconsole(.sf.net), and all other efforts are semi-ignored by The Mighty Ones (Linus, Alan etc.) IMHO, console should not be part of the kernel (or such a complicated one as we have today). It should be a userspace application, sitting on top of framebuffer or (for simpler cases) plain VGA hardware. With dynamic font downloading (see dynafont) it could be pretty impressive even in VGA text mode, and could have some limited CJK and BiDi support. First such thing is iterm, we'll see where if it can grow up to fulfil the expectations. -- ----------------------------------------------------------- | Radovan Garab�k http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__ garabik @ melkor.dnp.fmph.uniba.sk | ----------------------------------------------------------- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
