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? ... Jungshik -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
