bug#12868: global keymap preceeds input-decode-map

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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