Combined Yorùbá characters with dot below and tonal diacritics

[Ilya Zakharevich]

On Sun, Apr 12, 2015 at 07:07:01AM +0200, Philippe Verdy wrote:
> > 1) the characters required do not all exist as precomposed characters
> thus microsoft's dead key sequences will not work for yoruba.

    (As I said in my other email, the conclusion is wrong.)

> It's effectively a good catch that MSKLC (version 1.4) cannot produce
> sequences of characters (just one code point) with dead key sequences or
> anywhere it its keymap (independantly of the current keyboard state).

Irrelevant — due to the way the kernel processes a combination of
   1. Prefix key
   2. Key producing a multi-char string.

> This is effectively a strong limitation. Dropping that limitation would
> require updating the parsing format of the *.klc files to accept strings or
> sequences of codepoints, and also update the internal code of its generated
> driver so that it can map to a string (that the driver at run time will
> send with multiple WM_CHAR events)

This shows that you have no clue about this topic.  Format of .klc
files is absolutely irrelevant here.  A .klc file is just one of
preprocessor steps — and the final result is a static table
controlling the kernel.

It is the format of THIS TABLE which is the relevant limitation.  And
as far as the topics we discuss here go, the .klc covers all the
relevant features of this table.

  (See microsoft’s header files for details: they are in kbd.h, with
   finer details documented in the documentation for my Perl module.) 

> For now, all you can do is to generate a keymap that generates single code
> points,

Wrong.

> and map additional keys for the combining characters needed.

Wrong — there is nothing special for combining characters.  Deadkeys
(prefix keys) map UTF-16 codepoints to UTF-16 codepoints — but the way
this interacts with multi-codepoint keys makes the Yorùbá input
possible.

> MSKLC does not provide a way to build another geometry and map geometric
> keys to vkeys (or the revers).

Again, this has nothing to do with MSKLC.

> Note also that (since always), MSKLC generated drivers have never allowed
> us to change the mapping of scancodes (from hardware keyboards) to virtual
> keys, aka "vkeys", or to "WM_SYSKEY" (this is hardwired in a lower internal
> level).

Wrong.  Look for any French or German keyboard.

> These drivers only map sequences of one or more "vkeys" (and a few
> supported states, it's not possible to add keyboard states other than CTRL,
> SHIFT, CAPSLOCK, ALTGR2, and custom states for dead keys)

How do you think I do it in my layout?

> to only one WM_CHAR.

I have no idea why you would mix in WM_* stuff into this discussion…

> And it's not possible to change the mapping of vkeys to WM_SYSCHAR
> (this is also hardwired at a lower level).

I have no clue what you are talking about now…

Ilya