GNU bug report logs - #76526
30.1; kill-this-buffer not works normally

Previous Next

To reply to this bug, email your comments to 76526 AT debbugs.gnu.org.

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

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

From: Magi Feeney <matrixfeeney <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 21:25:32 +0800

[Message part 1 (text/plain, inline)]

I tested the function kill-this-buffer with "emacs -Q", it consistently
gives the output:

"command-execute: kill-this-buffer must be bound to an event with
parameters"

and doesn't kill the current buffer.


In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
 cairo version 1.18.0) of 2025-02-24 built on lcy02-amd64-070
Repository revision: 2d442455d1b98a9f631889ca63f3c4f21d9062b5
Repository branch: master
System Description: Ubuntu 22.04.5 LTS

Configured using:
 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
 --without-xaw3d --with-modules --with-cairo
 --with-native-compilation=aot --with-pgtk --with-xinput2
 --with-tree-sitter 'CFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include'
 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
 -L/build/emacs/stage/usr/lib''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ 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 $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  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 compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media
puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived
epg rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils 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 65706 8820) (symbols 48 6702 0) (strings 32 16692 2342)
 (string-bytes 1 591472) (vectors 16 10272)
 (vector-slots 8 142405 6642) (floats 8 22 2) (intervals 56 291 0)
 (buffers 992 11))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Magi Feeney <matrixfeeney <at> gmail.com>
Cc: 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 21:10:24 +0200

tags 76526 notabug
thanks

> From: Magi Feeney <matrixfeeney <at> gmail.com>
> Date: Mon, 24 Feb 2025 21:25:32 +0800
> 
> I tested the function kill-this-buffer with "emacs -Q", it consistently
> gives the output:
> 
> "command-execute: kill-this-buffer must be bound to an event with
> parameters"
> 
> and doesn't kill the current buffer.

Yes.  This is the intended behavior.  The function's doc string says:

  This command must be bound to a mouse event, and can be reliably
  invoked only from the menu bar, otherwise it could decide to silently
  do nothing or signal an error.  Use ‘kill-current-buffer’ if you
  need to invoke a similar command from keyboard.

This is not a bug.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Magi Feeney <matrixfeeney <at> gmail.com>
Cc: 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 19:21:00 +0000

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

> tags 76526 notabug
> thanks
>
>> From: Magi Feeney <matrixfeeney <at> gmail.com>
>> Date: Mon, 24 Feb 2025 21:25:32 +0800
>>
>> I tested the function kill-this-buffer with "emacs -Q", it consistently
>> gives the output:
>>
>> "command-execute: kill-this-buffer must be bound to an event with
>> parameters"
>>
>> and doesn't kill the current buffer.
>
> Yes.  This is the intended behavior.  The function's doc string says:
>
>   This command must be bound to a mouse event, and can be reliably
>   invoked only from the menu bar, otherwise it could decide to silently
>   do nothing or signal an error.  Use ‘kill-current-buffer’ if you
>   need to invoke a similar command from keyboard.
>
> This is not a bug.

FWIW, I think we should improve this.  It's bad that we show this
command in M-x completions when we already know that it won't work.

Perhaps this particular command/function should also be renamed to
menu-bar--kill-this-buffer, or something like that, so that users aren't
mislead to think that they can invoke it outside the menu bar.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: matrixfeeney <at> gmail.com, 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 21:24:26 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 24 Feb 2025 19:21:00 +0000
> Cc: 76526 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > tags 76526 notabug
> > thanks
> >
> >> From: Magi Feeney <matrixfeeney <at> gmail.com>
> >> Date: Mon, 24 Feb 2025 21:25:32 +0800
> >>
> >> I tested the function kill-this-buffer with "emacs -Q", it consistently
> >> gives the output:
> >>
> >> "command-execute: kill-this-buffer must be bound to an event with
> >> parameters"
> >>
> >> and doesn't kill the current buffer.
> >
> > Yes.  This is the intended behavior.  The function's doc string says:
> >
> >   This command must be bound to a mouse event, and can be reliably
> >   invoked only from the menu bar, otherwise it could decide to silently
> >   do nothing or signal an error.  Use ‘kill-current-buffer’ if you
> >   need to invoke a similar command from keyboard.
> >
> > This is not a bug.
> 
> FWIW, I think we should improve this.  It's bad that we show this
> command in M-x completions when we already know that it won't work.
> 
> Perhaps this particular command/function should also be renamed to
> menu-bar--kill-this-buffer, or something like that, so that users aren't
> mislead to think that they can invoke it outside the menu bar.

I don't see how a different name will help.  What can be more explicit
than what the doc string, which is the first place users should look
when a command doesn't do what they expect?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: matrixfeeney <at> gmail.com, 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 19:35:53 +0000

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

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Mon, 24 Feb 2025 19:21:00 +0000
>> Cc: 76526 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > tags 76526 notabug
>> > thanks
>> >
>> >> From: Magi Feeney <matrixfeeney <at> gmail.com>
>> >> Date: Mon, 24 Feb 2025 21:25:32 +0800
>> >>
>> >> I tested the function kill-this-buffer with "emacs -Q", it consistently
>> >> gives the output:
>> >>
>> >> "command-execute: kill-this-buffer must be bound to an event with
>> >> parameters"
>> >>
>> >> and doesn't kill the current buffer.
>> >
>> > Yes.  This is the intended behavior.  The function's doc string says:
>> >
>> >   This command must be bound to a mouse event, and can be reliably
>> >   invoked only from the menu bar, otherwise it could decide to silently
>> >   do nothing or signal an error.  Use ‘kill-current-buffer’ if you
>> >   need to invoke a similar command from keyboard.
>> >
>> > This is not a bug.
>>
>> FWIW, I think we should improve this.  It's bad that we show this
>> command in M-x completions when we already know that it won't work.
>>
>> Perhaps this particular command/function should also be renamed to
>> menu-bar--kill-this-buffer, or something like that, so that users aren't
>> mislead to think that they can invoke it outside the menu bar.
>
> I don't see how a different name will help.  What can be more explicit
> than what the doc string, which is the first place users should look
> when a command doesn't do what they expect?

A different name is more explicit because you don't have to look at the
docstring.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: matrixfeeney <at> gmail.com, 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 21:45:53 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 24 Feb 2025 19:35:53 +0000
> Cc: matrixfeeney <at> gmail.com, 76526 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Mon, 24 Feb 2025 19:21:00 +0000
> >> Cc: 76526 <at> debbugs.gnu.org
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > tags 76526 notabug
> >> > thanks
> >> >
> >> >> From: Magi Feeney <matrixfeeney <at> gmail.com>
> >> >> Date: Mon, 24 Feb 2025 21:25:32 +0800
> >> >>
> >> >> I tested the function kill-this-buffer with "emacs -Q", it consistently
> >> >> gives the output:
> >> >>
> >> >> "command-execute: kill-this-buffer must be bound to an event with
> >> >> parameters"
> >> >>
> >> >> and doesn't kill the current buffer.
> >> >
> >> > Yes.  This is the intended behavior.  The function's doc string says:
> >> >
> >> >   This command must be bound to a mouse event, and can be reliably
> >> >   invoked only from the menu bar, otherwise it could decide to silently
> >> >   do nothing or signal an error.  Use ‘kill-current-buffer’ if you
> >> >   need to invoke a similar command from keyboard.
> >> >
> >> > This is not a bug.
> >>
> >> FWIW, I think we should improve this.  It's bad that we show this
> >> command in M-x completions when we already know that it won't work.
> >>
> >> Perhaps this particular command/function should also be renamed to
> >> menu-bar--kill-this-buffer, or something like that, so that users aren't
> >> mislead to think that they can invoke it outside the menu bar.
> >
> > I don't see how a different name will help.  What can be more explicit
> > than what the doc string, which is the first place users should look
> > when a command doesn't do what they expect?
> 
> A different name is more explicit because you don't have to look at the
> docstring.

When did it stop someone from complaining?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: matrixfeeney <at> gmail.com, 76526 <at> debbugs.gnu.org
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Mon, 24 Feb 2025 19:52:23 +0000

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

> When did it stop someone from complaining?

We do have our fair share of space bar heaters, that's true.

https://xkcd.com/1172/

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

From: Magi Feeney <matrixfeeney <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76526 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76526: 30.1; kill-this-buffer not works normally
Date: Tue, 25 Feb 2025 12:59:52 +0800

[Message part 1 (text/plain, inline)]

Thank you for the prompt response! kill-current-buffer works for me. In
addition, I agree that the name kill-this-buffer is a bit misleading,
because before 30.1, it had the same functionality as kill-current-buffer.
If it only applies to menu-bar now, making it explicit would be clearer,
just my humble opinion.

On Tue, 25 Feb 2025 at 03:52, Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > When did it stop someone from complaining?
>
> We do have our fair share of space bar heaters, that's true.
>
> https://xkcd.com/1172/
>

[Message part 2 (text/html, inline)]

Previous Next

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