emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kbd vs read-key-sequence


From: Stefan Monnier
Subject: Re: kbd vs read-key-sequence
Date: Sat, 03 Mar 2007 18:01:08 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux)

>     Yeah, probably.  But it's been the case sine Emacs-20.  And some of the
>     bindings which worked in Emacs-20 failed in Emacs-21, and some of the
>     binding that work in Emacs-21 will fail in Emacs-22, and the same for
>     Emacs-23 most likely.  And if you add modifiers it's even more likely
>     to fail.

> I was not following this thread.  Can someone summarize the problem
> as it is known?

Here is the problem: when a key is pressed which causes a non-ASCII char to
be inserted in a buffer, the translation from the key-event to the non-ASCII
char can happen at many different levels:
- before the event is passed to Lisp code
- in input-method
- in key-translation-map (using encoded-kb typically)
- in self-insert-command (using unibyte-char-to-multibyte)

Usually, the earlier the better, but historically we started by doing the
most case of the translation (e.g. latin-1) in self-insert-command.
Also the place where it's done depends on the kind of char, the kind of
input method (e.g. XIM or LEIM), whether we're in console mode or w32, or
X11, or ...

On the other side of the problem we have code written in the .emacs file
which tries to bind something to this key.  To work, this has to satisfy
the condition that when Emacs loads the .emacs file, the key it finds in the
define-key call corresponds to the form of the event after
key-translation-map (but before unibyte-char-to-multibyte if applicable).

An additional piece of the puzzle is that the key that Emacs finds in the
define-key call might not be the one that the user sees on her screen when
she edits her .emacs, depending on how she specifies the file's encoding.

Another source of fun is of course the lack/presence of unification which
means that the same glyph or char can have different codes.

And if you want it to work with modifiers, it's yet a bit more interesting
because the base-event is not always decoded (partly because of bugs,
I guess, but in some cases it's done on purpose.  IIRC an example of
purposefully keeping the base event untranslated is for cyrillic
input-method where `c' might map to a cyrillic char, but C-c and M-c should
stay unchanged).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]