Re: Canonical Mode Input Processing with multi-byte character sets

[Daniel Glassey <danglassey@xxxxxxxxxxxx>]

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/