GNU bug report logs - #13948
no key-binding-locus

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 13948 <at> debbugs.gnu.org, Brian Malehorn <bmalehorn <at> gmail.com>
Subject: bug#13948: no key-binding-locus
Date: Mon, 02 Jun 2014 09:55:26 -0400

>> 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

Previous Next

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