[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12868: global keymap preceeds input-decode-map
From: |
Stefan Guath |
Subject: |
bug#12868: global keymap preceeds input-decode-map |
Date: |
Mon, 12 Nov 2012 16:27:44 +0100 |
I understand, and agree that a timeout is a bad idea. This should be reflected
in the manual though, just as it is for local-function-key-map ("Entries in
local-function-key-map are ignored if they conflict with bindings made in the
minor mode, local, or global keymaps"). Maybe it should also point out the
consequences of binding escape sequences used as prefix for common function
keys, i.e. `ESC [' and `ESC O'. One could even consider to unable colliding
bindings to emphasize that you have to choose, rather than 'bugging out'
silently.
BTW, the manual states that "The intent of key-translation-map is for users to
map one character set to another, including ordinary characters normally bound
to self-insert-command." Does this mean that key-translation-map is the
recommended way to implement different layouts such as Colemak/Dvorak etc at
the lowest possible level?
If yes, in the case of remapping `o' to `y' (Colemak example), M-O would never
get through the input-decode-map filter and therefore never pop up to
key-translation-map in order to produce M-Y. Is that correct?
/Stefan
On 12 nov 2012, at 15:32, Stefan Monnier wrote:
>> emacs -nw -Q
>> (defun foo () (interactive) (message "foo"))
>> (global-set-key "\M-O" 'foo)
> [...]
>> Arrow keys now inserts A,B,C,D in buffer.
> [...]
>> 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.
>
> Indeed, thanks for bringing this up. The cause for the bug is that the
> rule for what goes first and what goes next is here ignored because we
> stop waiting for more input as soon as a real binding is found
> (i.e. right after M-O).
>
> The predicate that decides when to stop waiting for more input would
> need to say say "don't stop if we're in the middle of a potential
> input-decode-map rewrite". But then if you want to run `foo', you'd
> have the problem that after hitting M-O, Emacs will not actually run
> `foo' but will sit there waiting to see if the next key is one of
> [ABCD].
>
> The only way to get our cake and eat it too would be to use some kind of
> timeout, which we have resisted so far.
>
>
> Stefan