console input

[Bruno Haible <haible@ilog.fr>]

Markus Kuhn writes:
> E.g., think not only about
> combining characters, but also about Arabic final forms that become
> middle forms if you add another character without a space.

That's not an output issue, it's an input method issue. Because the
final/non-final forms (for Hebrew) or final/initial/medial/isolated forms
(for Arabic) are different Unicode code points.

About console input in general, I'm not sure how far we want to go. We could:

1. Permit the same keytable to be used with a console in 8-bit and in UTF-8
   mode. I have patches (relative to kbd-0.99) that do that. Essentially,
   the Unicode value is added for each keysym in the keysym tables. When
   loadkeys is called with a new command-line option --unicode, it stuffs
   into the kernel the Unicode values instead of the 8-bit values.

   Note that CapsLock doesn't work with Unicode keys, because a key action
   in the kernel is stored as 16 bits. Also, Unicode characters >= 0xf000
   cannot be used because this range is overloaded to other meanings.

2. Transfer a complete Compose table into the kernel. And/or introduce
   a magic key (Meta-U or something) which permits to type hexadecimal
   Unicode values.

3. Build "intelligent" input methods like the ones used in Yudit or Emacs.
   Now some Asian input methods require the use of huge dictionaries,
   so this definitely doesn't belong in the kernel. How to set up the
   communication between the kernel and the input method - in such a way
   that the kernel remains responsive even if the input methods hangs or
   gets an OOM ?

Bruno
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/