On Tue, 2004-02-24 at 06:51, Jungshik Shin wrote: > On Mon, 23 Feb 2004, Henry Spencer wrote: > > > On Thu, 19 Feb 2004, Markus Kuhn wrote: > > > [Things get even more tricky with the available experimental terminal > > > support (e.g., in XFree86's xterm) for combining characters such as > > > diacritical marks, which are characters with wcwidth()=0... > > > > Worse yet, when combining characters are being entered separately, one > > might wish that backspace erase only the latest combining character, not > > the whole sequence back to and including the base character. > > Even worse yet, it depends on when, who and where. If a 'grapheme' > (e.g. a 'syllable' in Indic scripts, Korean script) is being formed when > 'backspace' is entered, it's desirable to erase just one combining > character. For 'committed' graphemes, one want to erase the whole > character sequence making up a graphme. > > > Personally, I suspect that the best answer at this point is to concede > > that the kernel device drivers live permanently in the world of 8-bit > > character sets, and that functionality such as Unicode input editing > > belongs in a user-level daemon rather than in the kernel. The vast > > majority of user keyboard input already passes through at least one such > > daemon anyway, so there is no significant efficiency issue any more. > > You're probably right that issues above had better be dealt with > 'user-land' input methods/daemon/whatever if possible. But, then, > for characters that have been permitted (not in pre-editing stage), > 'user-land' input methods can't do much. Terminal emulators? ...
There is a project that has been working on a kernel module for this level of things http://sourceforge.net/projects/ktty HTH, Daniel -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
