bug#13948: no key-binding-locus

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

>> So implementing key-binding-locus would only be a small tweak of
>> the key lookup code: the first time you find the key, just return
>> the map you found it in, rather than the command it's supposed to
>> call.
> IIUC, it's slightly more complicated than just modifying the return
> value of a function.

Indeed, the code was not written with this in mind.  E.g. looking up
"C-c C-s" first looks up "C-c" which returns a new keymap which combines
the C-c part of all the active keymaps, and then we lookup C-s in that
"composed" map.

Tracking the origin would require changing the data representation
(which is visible to ELisp), so it could be tricky to do without
breaking compatibility (tho we do such risky changes on a regular
basis ;-)

> Another reason is that some keymaps might not even be stored in any
> variable (symbol's value cell) at all.

Yes, keeping track of the original keymap in which the binding is found
is one thing, but keeping track of where that keymap is coming from is
yet another.

I'd welcome a change in C-h k to try and show where the binding comes
from, and it'd be OK to implement it with the kind of code you showed
(i.e. something not 100% reliable).


        Stefan