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
> 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.
But they do work differently: If you have a global-map binding of
"M-O A", the input-decode-map remapping will take precedence, whereas
a function-key-map remapping would be ignored.
It's a tricky business.
> Yes, that was sort of what I meant, but I agree it was a bad idea.
I don't think it's a bad idea, but it seems difficult to come up with
a way to detect actual problematic cases and brings them to the
user's attention (without being annoying, that is).
The best moment to detect those problem is when the global map is
modified, but the functions that are involved are the same as for
input-decode-map ;-)
> 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-[.
Sounds right. I'll see about doing that.
Stefan
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.