GNU bug report logs - #77345
30.1; "C-h w" doesn't detect binding in the midst of an M-x invocation

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 77345 in the body.
You can then email your comments to 77345 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: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Emacs bugs <bug-gnu-emacs <at> gnu.org>
Subject: 30.1; "C-h w" doesn't detect binding in the midst of an M-x invocation
Date: Fri, 28 Mar 2025 15:13:54 -0400

1. Invoke "emacs -Q".
2. Switch to *scratch* buffer.
3. Do M-x and then type "eval-print-last-sexp", but don't press RET.
4. Do "C-h w RET" (i.e., select the default option of
   eval-print-last-sexp).
5. Expected: Message in the echo area noting that "eval-print-last-sexp"
   is bound to "C-j".  Observed: "eval-print-last-sexp is not on any
   key".


In GNU Emacs 30.1 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.49,
cairo version 1.18.4)
System Description: openSUSE Tumbleweed

Configured using:
 'configure --disable-build-details --without-pop --with-mailutils
 --with-native-compilation --without-hesiod --with-gameuser=:games
 --with-kerberos --with-kerberos5 --with-file-notification=inotify
 --with-modules --enable-autodepend --prefix=/usr
 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
 --localstatedir=/var --sharedstatedir=/var/lib
 --libexecdir=/usr/libexec --with-file-notification=yes
 --libdir=/usr/lib64
 --enable-locallisppath=/usr/share/emacs/30.1/site-lisp:/usr/share/emacs/site-lisp
 --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
 --with-gif --with-png --with-rsvg --with-dbus --with-webp --with-xft
 --with-imagemagick --without-gpm --with-x-toolkit=gtk3 --with-pgtk
 --with-toolkit-scroll-bars --x-includes=/usr/include
 --x-libraries=/lib64 --with-libotf --with-m17n-flt --with-cairo
 --build=x86_64-suse-linux --with-dumping=pdumper 'CFLAGS=-O2 -Wall
 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong
 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
 -Werror=return-type -flto=auto -g -D_GNU_SOURCE
 -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS
 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -fno-optimize-sibling-calls -DPDMP_BASE='\''"emacs-wayland"'\'''
 'LDFLAGS=-Wl,-O2 -Wl,--copy-dt-needed-entries''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LC_NUMERIC: POSIX
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils noutline outline icons kmacro
byte-opt gv bytecomp byte-compile facemenu two-column subr-x cl-extra
shortdoc text-property-search comp-common rx help-fns radix-tree
help-mode cl-loaddefs cl-lib thingatpt delsel lpr easy-mmode pcase rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 125733 13605) (symbols 48 19500 0) (strings 32 35330 1870)
 (string-bytes 1 988883) (vectors 16 16938)
 (vector-slots 8 640335 88836) (floats 8 92 2) (intervals 56 16146 9)
 (buffers 992 14))

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 77345 <at> debbugs.gnu.org
Subject: Re: bug#77345: 30.1; "C-h w" doesn't detect binding in the midst of
 an M-x invocation
Date: Sat, 29 Mar 2025 08:05:50 +0100

Hi,

Suhail Singh <suhailsingh247 <at> gmail.com> writes:

> 1. Invoke "emacs -Q".
> 2. Switch to *scratch* buffer.
> 3. Do M-x and then type "eval-print-last-sexp", but don't press RET.
> 4. Do "C-h w RET" (i.e., select the default option of
>    eval-print-last-sexp).
> 5. Expected: Message in the echo area noting that "eval-print-last-sexp"
>    is bound to "C-j".  Observed: "eval-print-last-sexp is not on any
>    key".

You're asking "where is eval-print-last-sexp" in the minibuffer, not in
the original buffer.  So the observed response, "nowhere", is expected.
To see the binding in the original buffer, invoke C-h w in that buffer.


Best regards,

Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 77345 <at> debbugs.gnu.org
Subject: Re: bug#77345: 30.1;
 "C-h w" doesn't detect binding in the midst of an M-x invocation
Date: Sat, 29 Mar 2025 10:34:27 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Date: Fri, 28 Mar 2025 15:13:54 -0400
> 
> 
> 1. Invoke "emacs -Q".
> 2. Switch to *scratch* buffer.
> 3. Do M-x and then type "eval-print-last-sexp", but don't press RET.
> 4. Do "C-h w RET" (i.e., select the default option of
>    eval-print-last-sexp).
> 5. Expected: Message in the echo area noting that "eval-print-last-sexp"
>    is bound to "C-j".  Observed: "eval-print-last-sexp is not on any
>    key".

C-j in the minibuffer is not bound to eval-print-last-sexp, and
eval-print-last-sexp is not bound to any key in the minibuffer.  So I
don't see any bug here.

If you try the same with eval-last-sexp, you will see the result you
expect, because "C-x C-e" _is_ bound in the minibuffer.

Why do you think there's a bug here?

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

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77345 <at> debbugs.gnu.org, Suhail Singh <suhailsingh247 <at> gmail.com>
Subject: Re: bug#77345: 30.1; "C-h w" doesn't detect binding in the midst of
 an M-x invocation
Date: Sat, 29 Mar 2025 11:22:39 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> C-j in the minibuffer is not bound to eval-print-last-sexp ...
>
> If you try the same with eval-last-sexp, you will see the result you
> expect, because "C-x C-e" _is_ bound in the minibuffer.
>
> Why do you think there's a bug here?

Yes, it's clear that it's looking for bindings in the minibuffer.  This
was unexpected because I was expecting to be able to look up the binding
in the original buffer (lisp-interaction-mode in this case).  Thinking
some more about it, perhaps this isn't a bug as much as it is a feature
request.  I'll describe my use-case below.

Sometimes, I know (roughly) the name of the command, but not the
keybinding for it.  So I begin my journey by invoking M-x and rely on
TAB completion.  Having found the right command, I want to do two
things: one, invoke it; two, learn the keybinding if there is one
present.

To accomplish the latter, I have `marginalia' installed from ELPA, and
it adds annotations for keybindings in the completions buffer.  However,
if a completion is a sole completion then the completions buffer doesn't
show (see `minibuffer-completion-help').  The result is that for sole
completions, marginalia's keybinding annotations aren't accessible.

Running into this obstacle, I reached for the venerable `where-is'.
However, C-h w results in the lookup of bindings in the minibuffer
instead (as opposed to the original buffer where the M-x was invoked
from).

Of course completing the M-x invocation (or aborting it) and looking up
the binding of the command via C-h w in the original buffer works, but
it's a two-step process.

Some thoughts on possible ways this could be addressed:

- adding a user configuration which allows the completions buffer to be
  displayed even for sole completions
- adding an optional parameter for C-h w to be able to consult the
  binding in the original buffer (assuming the result reported by
  something like src_elisp{(window-buffer (minibuffer-selected-window))}
  is reliable for this purpose).

-- 
Suhail

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 77345 <at> debbugs.gnu.org
Subject: Re: bug#77345: 30.1; "C-h w" doesn't detect binding in the midst of
 an M-x invocation
Date: Sat, 29 Mar 2025 18:42:32 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: Suhail Singh <suhailsingh247 <at> gmail.com>,  77345 <at> debbugs.gnu.org
> Date: Sat, 29 Mar 2025 11:22:39 -0400
> 
> Sometimes, I know (roughly) the name of the command, but not the
> keybinding for it.  So I begin my journey by invoking M-x and rely on
> TAB completion.  Having found the right command, I want to do two
> things: one, invoke it; two, learn the keybinding if there is one
> present.

Unless you turn OFF suggest-key-bindings, "M-x" will always show you
in the echo-area the key binding of the last command you invoked.  Why
is that not enough?

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

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77345 <at> debbugs.gnu.org, Suhail Singh <suhailsingh247 <at> gmail.com>
Subject: Re: bug#77345: 30.1; "C-h w" doesn't detect binding in the midst of
 an M-x invocation
Date: Sat, 29 Mar 2025 15:18:50 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Unless you turn OFF suggest-key-bindings

Thank you for the reference to `suggest-key-bindings'.

> "M-x" will always show you in the echo-area the key binding of the
> last command you invoked.  Why is that not enough?

I had found the duration to be too brief.  However, now that I know that
`suggest-key-bindings' is the relevant defcustom, I also know that it
can be used to specify the duration.  Thank you.

This is sufficient for my needs.  I don't think the extension to "C-h w"
is warranted.

However, allowing for the completions buffer to be accessible even for
sole completions (based on user preference) may still have some value.
Specifically, it would allow other kinds of marginalia annotations that
a user finds relevant to be visible in the case of sole completions.
Currently this is an unaddressed edge case.

-- 
Suhail

Message #25 received at 77345-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 77345-done <at> debbugs.gnu.org
Subject: Re: bug#77345: 30.1; "C-h w" doesn't detect binding in the midst of
 an M-x invocation
Date: Sun, 13 Apr 2025 10:11:32 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: Suhail Singh <suhailsingh247 <at> gmail.com>,  77345 <at> debbugs.gnu.org
> Date: Sat, 29 Mar 2025 15:18:50 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Unless you turn OFF suggest-key-bindings
> 
> Thank you for the reference to `suggest-key-bindings'.
> 
> > "M-x" will always show you in the echo-area the key binding of the
> > last command you invoked.  Why is that not enough?
> 
> I had found the duration to be too brief.  However, now that I know that
> `suggest-key-bindings' is the relevant defcustom, I also know that it
> can be used to specify the duration.  Thank you.
> 
> This is sufficient for my needs.  I don't think the extension to "C-h w"
> is warranted.
> 
> However, allowing for the completions buffer to be accessible even for
> sole completions (based on user preference) may still have some value.
> Specifically, it would allow other kinds of marginalia annotations that
> a user finds relevant to be visible in the case of sole completions.
> Currently this is an unaddressed edge case.

No further comments, so I'm now closing this bug.

Previous Next

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