--- Begin Message ---
|
Subject: |
global keymap preceeds input-decode-map |
|
Date: |
Mon, 12 Nov 2012 10:06:38 +0100 |
emacs-version: GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
of 2012-08-27 on bob.porkrind.org
To trigger bug:
emacs -nw -Q
(defun foo () (interactive) (message "foo"))
(global-set-key "\M-O" 'foo)
Bug symptons:
Arrow keys now inserts A,B,C,D in buffer.
Suggested bug reason:
Arrow keys sends M-O A (up), M-O B (down) etc. These should be translated to
function keys <up>, <down> etc in input-decode-map before any key lookup.
Somehow, the binding of M-O in the global keymap takes precedence. This would
be expected with local-function-key-map as described in
http://www.gnu.org/software/emacs/manual/html_node/elisp/Translation-Keymaps.html
, but not with input-decode-map.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#12868: global keymap preceeds input-decode-map |
|
Date: |
Thu, 15 Nov 2012 09:17:01 -0500 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
I've installed the patch below to try and better explain what's going on
and warn about possible problems.
Stefan
=== modified file 'doc/lispref/ChangeLog'
--- doc/lispref/ChangeLog 2012-11-15 05:25:05 +0000
+++ doc/lispref/ChangeLog 2012-11-15 14:15:36 +0000
@@ -1,3 +1,8 @@
+2012-11-15 Stefan Monnier <address@hidden>
+
+ * keymaps.texi (Translation Keymaps): Add a subsection "Interaction
+ with normal keymaps".
+
2012-11-15 Dmitry Antipov <address@hidden>
* internals.texi (Garbage Collection): Update descriptions
=== modified file 'doc/lispref/keymaps.texi'
--- doc/lispref/keymaps.texi 2012-10-28 14:56:51 +0000
+++ doc/lispref/keymaps.texi 2012-11-15 14:12:01 +0000
@@ -1540,14 +1540,11 @@
being read, as it is read, against @code{input-decode-map}, then
@code{local-function-key-map}, and then against @code{key-translation-map}.
address@hidden input-decode-map
-This variable holds a keymap that describes the character sequences sent
-by function keys on an ordinary character terminal. This keymap has the
-same structure as other keymaps, but is used differently: it specifies
-translations to make while reading key sequences, rather than bindings
-for key sequences.
+These keymaps have the same structure as other keymaps, but they are used
+differently: they specify translations to make while reading key sequences,
+rather than bindings for key sequences.
-If @code{input-decode-map} ``binds'' a key sequence @var{k} to a vector
+If one of these keymaps ``binds'' a key sequence @var{k} to a vector
@var{v}, then when @var{k} appears as a subsequence @emph{anywhere} in a
key sequence, it is replaced with the events in @var{v}.
@@ -1562,6 +1559,10 @@
this back into @kbd{C-c @key{PF1}}, which it returns as the vector
@code{[?\C-c pf1]}.
address@hidden input-decode-map
+This variable holds a keymap that describes the character sequences sent
+by function keys on an ordinary character terminal.
+
The value of @code{input-decode-map} is usually set up automatically
according to the terminal's Terminfo or Termcap entry, but sometimes
those need help from terminal-specific Lisp files. Emacs comes with
@@ -1636,8 +1637,6 @@
(let ((symbol (if (symbolp e) e (car e))))
(setq symbol (intern (concat string
(symbol-name symbol))))
address@hidden group
address@hidden
(if (symbolp e)
symbol
(cons symbol (cdr e)))))
@@ -1647,10 +1646,30 @@
@end example
If you have enabled keyboard character set decoding using
address@hidden, decoding is done after the
-translations listed above. @xref{Terminal I/O Encoding}. However, in
-future Emacs versions, character set decoding may be done at an
-earlier stage.
address@hidden, decoding is done before the
+translations listed above. @xref{Terminal I/O Encoding}.
+
address@hidden Interaction with normal keymaps
+
+The end of a key sequence is detected when that key sequence either is bound
+to a command, or when Emacs determines that no additional event can lead
+to a sequence that is bound to a command.
+
+This means that, while @code{input-decode-map} and @code{key-translation-map}
+apply regardless of whether the original key sequence would have a binding, the
+presence of such a binding can still prevent translation from taking place.
+For example, let us return to our VT100 example above and add a binding for
address@hidden @key{ESC}} to the global map; now when the user hits @kbd{C-c
address@hidden Emacs will fail to decode @kbd{C-c @key{ESC} O P} into @kbd{C-c
address@hidden because it will stop reading keys right after @kbd{C-x
@key{ESC}},
+leaving @kbd{O P} for later. This is in case the user really hit @kbd{C-c
address@hidden, in which case Emacs should not sit there waiting for the next
key
+to decide whether the user really pressed @address@hidden or @address@hidden
+
+For that reason, it is better to avoid binding commands to key sequences where
+the end of the key sequence is a prefix of a key translation. The main such
+problematic suffixes/prefixes are @address@hidden, @kbd{M-O} (which is really
address@hidden@key{ESC} O}) and @kbd{M-[} (which is really @address@hidden [}).
@node Key Binding Commands
@section Commands for Binding Keys
--- End Message ---