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

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

bug#42207: 28.0.50; (where-is-internal) reports incorrect binding


From: Stefan Kangas
Subject: bug#42207: 28.0.50; (where-is-internal) reports incorrect binding
Date: Tue, 19 Oct 2021 16:43:17 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Dima Kogan <dima@secretsauce.net> writes:

> Hi. I'm using a pretty recent emacs built from git, although I don't
> think this bug is a recent regression. From a user perspective, the
> issue looks like this:
>
> 1. emacs -Q
> 2. Open any .py file, or just M-x python mode
> 3. M-x forward-se [TAB]
>
> Step 3 asks emacs to complete. There're two matches: forward-sexp and
> forward-sentence. Emacs also helpfully reports the associated bindings
> with each command because suggest-key-bindings is not nil. It says
> that the binding for forward-sentence is M-e, which is NOT the case
> here: M-e is python-nav-forward-block.

Hmm, isn't this basically what you would expect when you remap a
command?  That is, the thing that is actually bound to that key *is*,
properly speaking `forward-sexp'.  It's just that it's remapped to
`python-nav-forward-block'?

That said, I suppose our presentation of this could be smarter, but I'm
not sure what that would look like.  Just not showing the key-binding
for `forward-sentence' doesn't seem right either, does it?

> Digging a bit, I see that the issue is that we call (where-is-internal)
> in simple.el, and this is the issue:
>
>   (key-description (where-is-internal 'forward-sentence nil t))
>
> returns
>
>   "M-e", even in python-mode
>
> This maybe is related to the way this keymap is defined. python-mode-map is
>
>   (keymap
>    .... keys keys keys ...
>    (remap keymap
>           (mark-defun . python-mark-defun)
>           (backward-up-list . python-nav-backward-up-list)
>           (forward-sentence . python-nav-forward-block)
>           (backward-sentence . python-nav-backward-block))
>    ...
>   )
>
> I haven't read about this remap thing yet, and the docstring for
> (where-is-internal) does have a NO-REMAP option, but "M-e" is reported
> regardless of the value of NO-REMAP.
>
> Thanks.





reply via email to

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