Re: kbd vs read-key-sequence

[Kenichi Handa <handa@m17n.org>]

In article <E1HTACo-0003Q9-5f@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     At first, encoded-kbd-mode is designed to be used in the
>     case that Emacs is invoked with -nw, 

> I am not sure what that statement means.  Does it mean that

>    encoded-kbd-mode was designed originally to be used in -nw

> or does it mean that

>    encoded-kbd-mode is intended originally to be used in -nw

> Which one?

Both.  It was designed to be used in -nw and it still keeps
that design, and thus it is intended to be used in -nw.
Please note that "decoding" means to convert a byte sequence
to a character sequence.  On terminal, what Emacs receives
is surely a byte sequnece.  But on windows, what Emacs
receive is an window event, and it's a responsibility of
window-event handler to convert it to a character event.
And what window-event handler returns is a character,
applying "decoding" on it is not the right thing.

>     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.

> That might be a good thing, but since you can't do it now,
> can we fix encoded-kbd-mode to handle modifiers correctly?
> It probably is not very hard.

Implementing it in C doesn't solve the current problem.
Still, Windows code should be fixed to generate a correct
(multibyte) character event.  And, once Windows code is
fixed, we don't have to touch encoded-kbd-mode now.

And, changing encoded-kbd-mode is not very hard, but hard
enough to make me hesitate to do before the release.

> > We could recommend that people write (meta ?<encoded-?>).
> > That would eliminate this particular problem, right?

> No.  It would make it work on those systems which have the bug (e.g. w32
> right now), but would not work on systems where read-key-sequence correctly
> decodes such a key-combination into ?\M-é.

> I do not follow that argument.  If users write (meta ?<encoded-?>),
> why would that cause any problem anywhere?

Here, I think what he meant by "(meta ?<encoded-?>)" is a
code something like this ("\351" part is of 4 chars):

(global-set-key [(meta ?\351)] ...)

Then, it works only for w32.  Another way is to visit .emacs
as unibyte file, put "coding: raw-text;" tag, write as below
("\351" part is of 1 eight-bit char), and save it as
raw-text.

(global-set-key [(meta ?\351)] ...)

But, this also works only for w32.

Both depends on that the event ?\M-\351 is generated, but X
generates ?\M-é.

> I don't think it'll really be reliable, but we can definitely provide
> guidelines and hints.

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

> What should be used instead?  If there is nothing that works,
> I suggest that people who care about Windows support either fix this
> now, or implement something else now.

I do suggest the former.

I don't know how Windows port handles a keyboad event, but
considering that it depends on encoded-kbd-mode to work,
perhaps it returns a raw-byte (maybe with modifiers)
sequence as a character event sequence.  What it should do
is to decode those raw-bytes by locale-coding-system.

In emacs-unicode-2, I think it is much easier because I
believe Windows itself has a facility to convert keyboard
events to Unicode character.

---
Kenichi Handa
handa@m17n.org