GNU bug report logs - #12868
global keymap preceeds input-decode-map

Previous Next

Full log

Message #17 received at 12868 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Guath <stefan <at> automata.se>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 12868 <at> debbugs.gnu.org
Subject: Re: 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!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.