[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 18:31:48 +0100 |
On 12 nov 2012, at 18:03, Stefan Monnier wrote:
>> 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").
>
> I find it difficult to describe in a precise way without being
> too detailed, but I'll see what I can come up with.
The input-decode-map section could just have the exact same sentence as
local-function-key-map has, i.e. "Entries in input-decode-map are ignored if
they conflict with bindings made in the minor mode, local, or global keymaps".
Since local-function-key-map has that sentence, and input-decode-map does not,
one assume that they work differently. Which is not the case.
The key-translation-map section is plain out wrong: "Just like
input-decode-map, but unlike local-function-key-map, this keymap is applied
regardless of whether the input key-sequence has a normal binding." No,
input-decode-map nor key-translation-map has precedence over normal bindings -
it's just the other way around.
>> 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.
>
> Can you expand on what you mean by "unable colliding bindings". Do you
> mean that in your test case, Emacs should signal an error or at issue
> a warning, after seeing the M-O?
>
> Note that such colliding bindings already exist in the default config:
> "emacs -nw -Q" and then ESC ESC ESC will run keyboard-escape-quit even
> though the last ESC is a prefix of many function key escape sequences.
Yes, that was sort of what I meant, but I agree it was a bad idea. But the
manual could at least conclude the entire section 22.14 with a reminder that
since normal bindings do have precedence over all three of input-decode-map,
local-function-key-map and key-translation-map, it's a bad idea to bind
anything that collides with them such as `ESC O' or `ESC ['. People don't have
to understand why - just prevent them from binding M-O and M-[.
>> 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?
>
> No, I don't think so. But to tell you the truth, I do not know
> understand the reasoning behind key-translation-map.
Me neither... It's confusing...
> Also, I don't think there is a "recommended way" to provide such
> a remapping within Emacs, currently. Or rather than recommended way is
> probably to do the remapping outside of Emacs.
Thanks! I've struggled with this and always thought that I missed something
obvious.
>> 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?
>
> Yes, that's right.
Great - I thought I'd misunderstood something fundamental. Thanks for all the
clarifications!