encoded-kbd-mode

encoded-kbd-mode

[Richard Stallman]

Would you please explain to me the cause of the problems
in converting Meta characters?  I want to fully understand
why binding (meta ?é) won't work on Windows.

Re: encoded-kbd-mode

[Kenichi Handa]

In article <E1HXmsR-0000yZ-2g@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> Would you please explain to me the cause of the problems
> in converting Meta characters?  I want to fully understand
> why binding (meta ?é) won't work on Windows.

Encoded-kdb-mode is designed to convert raw-byte event
sequence into character event sequence by utilizing keymap
look-up mechanism.  So, it creates key-translation-map that
maps raw-byte events to proper commands or to deeper maps.

To make it handle a raw-byte event with modifers, we must
create key-bindings for all combinations of modifiers.  It
may leads to combinatorial-explosion.  We may be able to
catch all events by [t], but that requires another event
parsing state (extract modifiers from the event, remember it
in some variable, delete modifiers from the event, feed it
again to key-translation-map, modify the last character
event generator to handle the remembered modifiers, etc).

Another anxiety is for those Windows user who have already
found this workaround:
  (global-set-key [?\M-\351] ...)
If we make [?\M-é] work for Windows now, the above setting
stops working.  I think people accept such a breakage more
tolerantly if the change is for emacs-unicode.

---
Kenichi Handa
handa@m17n.org

Re: encoded-kbd-mode

[Richard Stallman]

    Encoded-kdb-mode is designed to convert raw-byte event
    sequence into character event sequence by utilizing keymap
    look-up mechanism.  So, it creates key-translation-map that
    maps raw-byte events to proper commands or to deeper maps.

    To make it handle a raw-byte event with modifers, we must
    create key-bindings for all combinations of modifiers.

That is one possible approach.  Another approach would be to have it
remove the modifier, convert the character, and then add the modifier
back.  Maybe that is easier.  It doesn't have to be done IN
encoded-kdb-mode.  It could be done by some higher level of input
processing.

      We may be able to
    catch all events by [t], but that requires another event
    parsing state (extract modifiers from the event, remember it
    in some variable, delete modifiers from the event, feed it
    again to key-translation-map, modify the last character
    event generator to handle the remembered modifiers, etc).

That doesn't sound very hard.  Would it fix the bug?

    Another anxiety is for those Windows user who have already
    found this workaround:
      (global-set-key [?\M-\351] ...)
    If we make [?\M-é] work for Windows now, the above setting
    stops working.

If anyone wants to complain that a bizarre and incorrect work-around
ceases to work, he will be satisfied when he learns that this is due
to a fix that makes "the right thing" work properly.