bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60530: 28.2; Add tools to find keymaps that bind a given command


From: Ruijie Yu
Subject: bug#60530: 28.2; Add tools to find keymaps that bind a given command
Date: Mon, 20 Feb 2023 21:44:31 +0800
User-agent: mu4e 1.8.13; emacs 29.0.60

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ruijie Yu <ruijie@netyu.xyz>
>> Cc: spd@toadstyle.org, 60530@debbugs.gnu.org
>> Date: Mon, 20 Feb 2023 20:01:27 +0800
>>
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Cc: 60530@debbugs.gnu.org
>> >> Date: Mon, 20 Feb 2023 15:07:09 +0800
>> >> From:  Ruijie Yu via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >>
>> >> I saw this message long ago, but recently I came across a situation
>> >> where I wanted to know if a command was bound in *some* keymap whose
>> >> name I didn't know, and this would be quite a helpful feature for me
>> >> personally (pun intended).
>> >
>> > Isn't that what where-is and/or where-is-internal already do?
>>
>> No, not quite.  The functions where-is{,-internal} only look for
>> *currently active keymaps*, whereas my intention was to look for all
>> keybinds for the specified command, be it active or not.
>
> But that's impossible in principle, because loading some package could
> produce a binding for a command, and you don't know which packages
> will be loaded into a session before they are actually loaded.
>
> Or what am I missing?

My idea is to only use the "current state" (whatever that might mean)
for searching for keybinds, and that criterion should exclude things
like autoload, as the key isn't bound until the package is properly
loaded.

So IMO, the only difference between `where-is' and this new function
would be this: instead of looking for active keymaps, the new function
looks for all existing (named) keymaps from `obarray' -- and do the same
action of scanning over the list of keymaps and figure out what
information to show to the user.

But anyways, this can absolutely be simply user-local code, and doesn't
have to live inside emacs.git.

>> The following is my reason to want this feature.  I use pyim, an input
>> method that shows candidate words in a small frame (which I believe is
>> called posframe?), which has `pyim-mode-map' enabled.  Then, while
>> typing, I want to know how to call the `pyim-next-page' command without
>> going into pyim source.
>>
>> If I type M-x where-is, this frame disappears, and I am dropped back
>> into the editing buffer, which does not have `pyim-mode-map' enabled.
>> Hence, `where-is' does not show anything bound for `pyim-next-page',
>> because it indeed is not bound globally.  FTR, C-h b does not work
>> either.
>
> If what where-is does doesn't suit your needs for reasons of its UI or
> how it switches buffers, you could extract (parts of) its code and
> make a similar function which presents the results in a way that
> doesn't interrupt your workflow.  My point in mentioning the existing
> commands is that they already show how to find bindings for an
> arbitrary command, so you could reuse some or all of that code for
> your purposes (which sound very similar to me).

I understand and agree.  See above for further comments.

--
Best,


RY





reply via email to

[Prev in Thread] Current Thread [Next in Thread]