GNU bug report logs - #42207
28.0.50; (where-is-internal) reports incorrect binding

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42207 in the body.
You can then email your comments to 42207 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; (where-is-internal) reports incorrect binding
Date: Sat, 04 Jul 2020 16:01:50 -0700

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.

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.





Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/28.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.0.50/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/28.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/28.0.50/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-snapshot-MVBGWo/emacs-snapshot-20200426+emacs-27.0.91-703-g453ada0309d=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall
 -fno-omit-frame-pointer' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
 LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_ALL: C
  value of $LANG: C
  locale-coding-system: nil

Message #8 received at 42207 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 42207 <at> debbugs.gnu.org
Subject: Re: bug#42207: 28.0.50; (where-is-internal) reports incorrect binding
Date: Tue, 19 Oct 2021 16:43:17 -0700

Dima Kogan <dima <at> 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.

Message #13 received at 42207 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 42207 <at> debbugs.gnu.org, 23543 <at> debbugs.gnu.org
Subject: Re: bug#42207: 28.0.50; (where-is-internal) reports incorrect binding
Date: Mon, 06 Jun 2022 16:43:36 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> (define-key global-map [remap eval-last-sexp] 'pp-eval-last-sexp)
>>
>> Put point after a Lisp sexp somewhere, and do `M-x eval-last-sexp'.
>>
>> You see this echoed:
>>
>>   You can run the command 'eval-last-sexp' with C-x C-e
>>
>> But that is incorrect.  You cannot run `eval-last-sexp'
>> using `C-x C-e', since it has been remapped to command
>> `pp-eval-last-sexp'.  If you use `C-x C-e' you invoke
>> the latter, not `eval-last-sexp'.
>
> I can confirm that this is still present in Emacs 27.

I've now fixed this in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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