GNU bug report logs -
#12868
global keymap preceeds input-decode-map
Previous Next
Reported by: Stefan Guath <stefan <at> automata.se>
Date: Mon, 12 Nov 2012 09:08:02 UTC
Severity: normal
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#12868: global keymap preceeds input-decode-map
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 12868 <at> debbugs.gnu.org.
--
12868: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12868
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 <monnier <at> iro.umontreal.ca>
+
+ * keymaps.texi (Translation Keymaps): Add a subsection "Interaction
+ with normal keymaps".
+
2012-11-15 Dmitry Antipov <dmantipov <at> yandex.ru>
* 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}.
-@defvar 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]}.
+@defvar 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))))
-@end group
-@group
(if (symbolp e)
symbol
(cons symbol (cdr e)))))
@@ -1647,10 +1646,30 @@
@end example
If you have enabled keyboard character set decoding using
-@code{set-keyboard-coding-system}, 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.
+@code{set-keyboard-coding-system}, decoding is done before the
+translations listed above. @xref{Terminal I/O Encoding}.
+
+@subsection 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
+@kbd{C-c @key{ESC}} to the global map; now when the user hits @kbd{C-c
+@key{PF1}} Emacs will fail to decode @kbd{C-c @key{ESC} O P} into @kbd{C-c
+@key{PF1}} 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
+@key{ESC}}, in which case Emacs should not sit there waiting for the next key
+to decide whether the user really pressed @kbd{@key{ESC}} or @kbd{@key{PF1}}.
+
+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 @kbd{@key{ESC}}, @kbd{M-O} (which is really
+@kbd{@key{ESC} O}) and @kbd{M-[} (which is really @kbd{@key{ESC} [}).
@node Key Binding Commands
@section Commands for Binding Keys
[Message part 3 (message/rfc822, inline)]
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.
This bug report was last modified 12 years and 253 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.