Re: kbd vs read-key-sequence

[Stefan Monnier]

>> >     Because the way the event is decoded through read-key-sequence is
>> >     not necessarily the same.  E.g. while ?<encoded-?> may get turned
>> >     into ??, it may be the case that ?\M-<encoded-?> stays unchanged.

>> > How does that happen?

>> See the OP.  It seems that encoded-kb.el has such a limitation (it should
>> probably be considered as a bug, but there may be good reasons for it,
>> I don't know).

> At first, encoded-kbd-mode is designed to be used in the case that Emacs
> is invoked with -nw, and it uses key-translation-map to handle character
> events from 0 to 255 (that's all what happens with -nw).

That's true, so it's probably the reason for the limitation: all meta keys
are expected to come with an ESC prefix, so the code has no good reason to
handle ?\M-<foo> chars.

> I think the following diagram is the right thing to do:

>        window-system        terminal
>              |                 |
>              | window event    | character event 0..255
>              |                 |
>        handle_one_xevent    keyboad-coding-system decoder
>               \               /
>                \ lispy event /
>                 \           /
>                  \         /
>                   read_char
>                       |
>                  input method
>                       |
>                    keymap

Agreed.

> And, it's in my todo list to abolish encoded-kbd-mode and
> implement keyboard-coding-system decoder in C for long, but
> unfortunately I still don't have a time to do that.

Does it have to be done in C?

> As shown in the previous diagram, I think it's a bug of w32
> code if it doesn't convert such an event as ?\M-<encoded-?>
> into ?\M-é because only a window system generates such an
> event and knows how to encode it.

Agreed.  The bug is that w32 shouldn't be using encoded-kb.

> One guideline is not to use encoded-kbd-mode on window system.

But that's the only available way in w32, IIUC.


        Stefan