all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: spd@toadstyle.org, 60530@debbugs.gnu.org
Subject: bug#60530: 28.2; Add tools to find keymaps that bind a given command
Date: Mon, 20 Feb 2023 21:44:31 +0800	[thread overview]
Message-ID: <sdvv8jwl8tl.fsf@fw.net.yu> (raw)
In-Reply-To: <83ilfwv5yz.fsf@gnu.org>


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	other threads:[~2023-02-20 13:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03 22:30 bug#60530: 28.2; Add tools to find keymaps that bind a given command Sean Devlin
2023-02-20  7:07 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-20 11:54   ` Eli Zaretskii
2023-02-20 12:01     ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-20 13:09       ` Eli Zaretskii
2023-02-20 13:44         ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sdvv8jwl8tl.fsf@fw.net.yu \
    --to=bug-gnu-emacs@gnu.org \
    --cc=60530@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=ruijie@netyu.xyz \
    --cc=spd@toadstyle.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.