GNU bug report logs - #78809
30.1.90; kill-this-buffer regression

Previous Next

To reply to this bug, email your comments to 78809 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1.90; kill-this-buffer regression
Date: Tue, 17 Jun 2025 00:20:32 +0200

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

0. emacs -Q
1. Type the <f10> key to open menu "File" from the menu bar, navigate
   (with the <down> key) to item "Close" and hit RET.
=> The *scratch* buffer is killed, making the *Messages* buffer current.
2. Type `M-x menu-bar-mode' to remove the menu bar.
3. Type `M-x scratch-buffer' to recreate the *scratch* buffer.
4. Type `C-down-mouse-3' to open the Global Menu pop-up menu, navigate
   in it to submenu "File", which pops open, and within that submenu
   navigate to item "Close", and then the press mouse-1.
=> The *scratch* buffer is killed, making the *Messages* buffer current.
5. Type `M-x scratch-buffer' to recreate the *scratch* buffer again.
6. Type the <f10> key, which now (because there is no menu bar) opens
   the Global Menu pop-up menu, navigate in it to submenu "File", which
   pops open, and within that submenu navigate to item "Close" and hit
   RET.
=> The *scratch* buffer remains current, Emacs beeps and displays the
   message "kill-this-buffer must be bound to an event with parameters".

When carrying out the above recipe in Emacs 29 (and presumably also in
earlier versions), the result of step 6 is the same as in step 1 and
step 5.  The change in behavior is due to commit 627d60910b, which added
"e" to the interactive form of `kill-this-buffer', limiting interactive
calls to non-keyboard events.

Evidently, invoking `menu-bar-open' by typing <f10> counts as a mouse
event only when the menu bar is present.  When the menu bar is removed,
the crucial difference is whether the Global Menu pop-up menu is opened
by using the mouse or the keyboard: in particular, in step 6, after
opening the pop-up menu with <f10>, navigating with the mouse to the
submenu "File" and then to the item "Close" and then clicking mouse-1
raises the error instead of killing the *scratch* buffer; while in step
4, after opening the pop-up menu with `C-down-mouse-3', navigating with
the <down> key to "File" and then further to "Close" and then hitting
RET kills the *scratch* buffer.

IIUC adding the interactive code character "e" in commit 627d60910b was
done to prevent invoking `kill-this-buffer' via M-x and also from the
minibuffer even via the global menu (see bug#8184 and bug#26466), though
the commit message only says it fixes "kill-this-buffer's detection of
minibuffer frames".  It seems that the regression in step 6 above is
unintended fallout.  (Note that this regression also prevents calling
`kill-this-buffer' via <f10> when Emacs is running in a text terminal,
though calling it using a mouse is possible with `xterm-mouse-mode'
enabled.)  The attached patch fixes this regression by dispensing with
the "e" interactive code and instead using last-command-event to
determine whether the invocation of `kill-this-buffer' comes from a menu
irrespective of whether the menu is opened by a mouse or keyboard event.

Since commit bc55a57423 the doc string of `kill-this-buffer' includes
this text: "This command can be reliably invoked only from the menu bar,
otherwise it could decide to silently do nothing."  But in fact, it is
also callable from the tool bar (and AFAICT has been since tool bars
were first added to Emacs 21).  The attached patch also takes this into
account.

Commit 627d60910b makes the EVENT argument of `kill-this-buffer'
optional.  Though the commit message does not say anything about this, I
assume it is for backward compatibility, since there are a few
noninteractive calls to `kill-this-buffer' in the Emacs sources.
However, these predate the introduction of `kill-current-buffer', which
was added in commit 2e4f4c9d48 in response to bug#26466.  That commit
also replaced numerous uses of `kill-this-buffer' by
`kill-current-buffer', but missed a few, so the attached patch completes
that job (except for two files in lisp/obsolete).  The patch also makes
it an error to call `kill-this-buffer' noninteractively.


In GNU Emacs 30.1.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-06-16 built on strobelfs2
Repository revision: a2bfce5d2a7d046a45c25364f3c69b3d8a776081
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Linux From Scratch r12.3-20

Configured using:
 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

[Message part 2 (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 78809 <at> debbugs.gnu.org
Subject: Re: bug#78809: 30.1.90; kill-this-buffer regression
Date: Tue, 17 Jun 2025 14:36:15 +0300

> Date: Tue, 17 Jun 2025 00:20:32 +0200
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 0. emacs -Q
> 1. Type the <f10> key to open menu "File" from the menu bar, navigate
>    (with the <down> key) to item "Close" and hit RET.
> => The *scratch* buffer is killed, making the *Messages* buffer current.
> 2. Type `M-x menu-bar-mode' to remove the menu bar.
> 3. Type `M-x scratch-buffer' to recreate the *scratch* buffer.
> 4. Type `C-down-mouse-3' to open the Global Menu pop-up menu, navigate
>    in it to submenu "File", which pops open, and within that submenu
>    navigate to item "Close", and then the press mouse-1.
> => The *scratch* buffer is killed, making the *Messages* buffer current.
> 5. Type `M-x scratch-buffer' to recreate the *scratch* buffer again.
> 6. Type the <f10> key, which now (because there is no menu bar) opens
>    the Global Menu pop-up menu, navigate in it to submenu "File", which
>    pops open, and within that submenu navigate to item "Close" and hit
>    RET.
> => The *scratch* buffer remains current, Emacs beeps and displays the
>    message "kill-this-buffer must be bound to an event with parameters".
> 
> When carrying out the above recipe in Emacs 29 (and presumably also in
> earlier versions), the result of step 6 is the same as in step 1 and
> step 5.  The change in behavior is due to commit 627d60910b, which added
> "e" to the interactive form of `kill-this-buffer', limiting interactive
> calls to non-keyboard events.
> 
> Evidently, invoking `menu-bar-open' by typing <f10> counts as a mouse
> event only when the menu bar is present.  When the menu bar is removed,
> the crucial difference is whether the Global Menu pop-up menu is opened
> by using the mouse or the keyboard: in particular, in step 6, after
> opening the pop-up menu with <f10>, navigating with the mouse to the
> submenu "File" and then to the item "Close" and then clicking mouse-1
> raises the error instead of killing the *scratch* buffer; while in step
> 4, after opening the pop-up menu with `C-down-mouse-3', navigating with
> the <down> key to "File" and then further to "Close" and then hitting
> RET kills the *scratch* buffer.
> 
> IIUC adding the interactive code character "e" in commit 627d60910b was
> done to prevent invoking `kill-this-buffer' via M-x and also from the
> minibuffer even via the global menu (see bug#8184 and bug#26466), though
> the commit message only says it fixes "kill-this-buffer's detection of
> minibuffer frames".  It seems that the regression in step 6 above is
> unintended fallout.  (Note that this regression also prevents calling
> `kill-this-buffer' via <f10> when Emacs is running in a text terminal,
> though calling it using a mouse is possible with `xterm-mouse-mode'
> enabled.)  The attached patch fixes this regression by dispensing with
> the "e" interactive code and instead using last-command-event to
> determine whether the invocation of `kill-this-buffer' comes from a menu
> irrespective of whether the menu is opened by a mouse or keyboard event.
> 
> Since commit bc55a57423 the doc string of `kill-this-buffer' includes
> this text: "This command can be reliably invoked only from the menu bar,
> otherwise it could decide to silently do nothing."  But in fact, it is
> also callable from the tool bar (and AFAICT has been since tool bars
> were first added to Emacs 21).  The attached patch also takes this into
> account.
> 
> Commit 627d60910b makes the EVENT argument of `kill-this-buffer'
> optional.  Though the commit message does not say anything about this, I
> assume it is for backward compatibility, since there are a few
> noninteractive calls to `kill-this-buffer' in the Emacs sources.
> However, these predate the introduction of `kill-current-buffer', which
> was added in commit 2e4f4c9d48 in response to bug#26466.  That commit
> also replaced numerous uses of `kill-this-buffer' by
> `kill-current-buffer', but missed a few, so the attached patch completes
> that job (except for two files in lisp/obsolete).  The patch also makes
> it an error to call `kill-this-buffer' noninteractively.

I don't like at all the fallout which was caused (and continues to be
caused) by the change, so I'm inclined to ignore these subtleties.
But given that you already did all the footwork, I'm okay with
installing these changes nonetheless.  Feel free to install on the
master branch, and thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78809 <at> debbugs.gnu.org
Subject: Re: bug#78809: 30.1.90; kill-this-buffer regression
Date: Tue, 17 Jun 2025 14:08:55 +0200

On Tue, 17 Jun 2025 14:36:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

[...]
>> enabled.)  The attached patch fixes this regression by dispensing with
>> the "e" interactive code and instead using last-command-event to
>> determine whether the invocation of `kill-this-buffer' comes from a menu
>> irrespective of whether the menu is opened by a mouse or keyboard event.
>> 
>> Since commit bc55a57423 the doc string of `kill-this-buffer' includes
>> this text: "This command can be reliably invoked only from the menu bar,
>> otherwise it could decide to silently do nothing."  But in fact, it is
>> also callable from the tool bar (and AFAICT has been since tool bars
>> were first added to Emacs 21).  The attached patch also takes this into
>> account.
>> 
>> Commit 627d60910b makes the EVENT argument of `kill-this-buffer'
>> optional.  Though the commit message does not say anything about this, I
>> assume it is for backward compatibility, since there are a few
>> noninteractive calls to `kill-this-buffer' in the Emacs sources.
>> However, these predate the introduction of `kill-current-buffer', which
>> was added in commit 2e4f4c9d48 in response to bug#26466.  That commit
>> also replaced numerous uses of `kill-this-buffer' by
>> `kill-current-buffer', but missed a few, so the attached patch completes
>> that job (except for two files in lisp/obsolete).  The patch also makes
>> it an error to call `kill-this-buffer' noninteractively.
>
> I don't like at all the fallout which was caused (and continues to be
> caused) by the change, so I'm inclined to ignore these subtleties.
> But given that you already did all the footwork, I'm okay with
> installing these changes nonetheless.  Feel free to install on the
> master branch, and thanks.

Thanks, but first let me double check: you do mean master even though
it's a regression in emacs-30?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 78809 <at> debbugs.gnu.org
Subject: Re: bug#78809: 30.1.90; kill-this-buffer regression
Date: Tue, 17 Jun 2025 15:18:51 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 78809 <at> debbugs.gnu.org
> Date: Tue, 17 Jun 2025 14:08:55 +0200
> 
> On Tue, 17 Jun 2025 14:36:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > I don't like at all the fallout which was caused (and continues to be
> > caused) by the change, so I'm inclined to ignore these subtleties.
> > But given that you already did all the footwork, I'm okay with
> > installing these changes nonetheless.  Feel free to install on the
> > master branch, and thanks.
> 
> Thanks, but first let me double check: you do mean master even though
> it's a regression in emacs-30?

Yes.  The documentation changes can go to emacs-30, if you want, but
the change in the interactive spec is too much for the release branch
at this time.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78809-done <at> debbugs.gnu.org
Subject: Re: bug#78809: 30.1.90; kill-this-buffer regression
Date: Tue, 17 Jun 2025 16:16:05 +0200

On Tue, 17 Jun 2025 15:18:51 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 78809 <at> debbugs.gnu.org
>> Date: Tue, 17 Jun 2025 14:08:55 +0200
>> 
>> On Tue, 17 Jun 2025 14:36:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>> > I don't like at all the fallout which was caused (and continues to be
>> > caused) by the change, so I'm inclined to ignore these subtleties.
>> > But given that you already did all the footwork, I'm okay with
>> > installing these changes nonetheless.  Feel free to install on the
>> > master branch, and thanks.
>> 
>> Thanks, but first let me double check: you do mean master even though
>> it's a regression in emacs-30?
>
> Yes.  The documentation changes can go to emacs-30, if you want, but
> the change in the interactive spec is too much for the release branch
> at this time.

Ok.  I think only the doc changes in emacs-30 could be confusing, since
it would still error if you use <f10> with the menu bar disabled, so
I've now pushed the changes to master in commit 79e50ddb9ca and am
closing the bug.  Thanks.

Steve Berman

Previous Next

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