bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

[Mattias]

kill-this-buffer is not working as before anymore.

Old behaviour:

e -Q
C-x 3
M-x kill-this-buffer

would kill the current buffer and display only one frame

e -Q
C-x 3
M-x kill-this-buffer

Will raise an error:

Debugger entered--Lisp error: (error "kill-this-buffer must be bound to 
an event with parameters")
command-execute(kill-this-buffer record)
execute-extended-command(nil "kill-this-buffer" "kill-th")
funcall-interactively(execute-extended-command nil "kill-this-buffer" 
"kill-th")
command-execute(execute-extended-command)



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0) of 2024-06-06 built on mattias-dell
Repository revision: a48f062e36be3ce5890a8a789272f31f074fea40
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.4 LTS

Configured using:
'configure --with-native-compilation --with-modules --with-harfbuzz
--without-compress-install --with-threads --with-included-regex
--with-x-toolkit=gtk3 --with-zlib --with-jpeg --with-png
--with-imagemagick --with-tiff --with-xpm --with-gnutls --with-xft
--with-xml2 --with-mailutils --with-tree-sitter'

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

Important settings:
value of $LC_COLLATE: C
value of $LC_CTYPE: en_US.UTF-8
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8

Major mode: ELisp/l

Memory information:
((conses 16 1540841 543034) (symbols 48 95597 5) (strings 32 500736 45391)
(string-bytes 1 12435212) (vectors 16 123738) (vector-slots 8 1471921 
261655)
(floats 8 2662 9349) (intervals 56 44616 14613) (buffers 992 58))

bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

[Eli Zaretskii]

tags 71510 notabug
thanks

> Date: Wed, 12 Jun 2024 11:06:36 +0200
> From: Mattias <mattias@kojin.tech>
> 
> 
> kill-this-buffer is not working as before anymore.
> 
> Old behaviour:
> 
> e -Q
> C-x 3
> M-x kill-this-buffer
> 
> would kill the current buffer and display only one frame
> 
> e -Q
> C-x 3
> M-x kill-this-buffer
> 
> Will raise an error:
> 
> Debugger entered--Lisp error: (error "kill-this-buffer must be bound to 
> an event with parameters")
> command-execute(kill-this-buffer record)
> execute-extended-command(nil "kill-this-buffer" "kill-th")
> funcall-interactively(execute-extended-command nil "kill-this-buffer" 
> "kill-th")
> command-execute(execute-extended-command)

This is the intended behavior, not a bug: this command must be invoked
from a mouse event.

bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 71510 notabug
> thanks
>
>> Date: Wed, 12 Jun 2024 11:06:36 +0200
>> From: Mattias <mattias@kojin.tech>
>> 
>> 
>> kill-this-buffer is not working as before anymore.
>> 
>> Old behaviour:
>> 
>> e -Q
>> C-x 3
>> M-x kill-this-buffer
>> 
>> would kill the current buffer and display only one frame
>> 
>> e -Q
>> C-x 3
>> M-x kill-this-buffer
>> 
>> Will raise an error:
>> 
>> Debugger entered--Lisp error: (error "kill-this-buffer must be bound to 
>> an event with parameters")
>> command-execute(kill-this-buffer record)
>> execute-extended-command(nil "kill-this-buffer" "kill-th")
>> funcall-interactively(execute-extended-command nil "kill-this-buffer" 
>> "kill-th")
>> command-execute(execute-extended-command)
>
> This is the intended behavior, not a bug: this command must be invoked
> from a mouse event.

Mattias, if it helps, such errors frequently indicate that the command
is being misapplied in contexts where `kill-current-buffer' is the
appropriate command.

bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

[Mattias]

Hi Eli,

Thanks for your answer. To make it clear, I don't pretend that it's a 
bug, I just noticed that the previous behaviour is no longer maintained. 
The doc associated to the function states that:

     When called in the minibuffer, get out of the minibuffer
     using `abort-recursive-edit'.

     This command can be reliably invoked only from the menu bar,
     otherwise it could decide to silently do nothing."

So it looks like now the behaviour is enforced but the error message is 
a bit underwhelming and the error trace doesn't help to understand 
what's happening.

Anyway, thanks a lot for your answer, I'll now use `kill-current-buffer`

Mattias

Le 12/06/2024 à 12:54, Eli Zaretskii a écrit :
> tags 71510 notabug
> thanks
>
>> Date: Wed, 12 Jun 2024 11:06:36 +0200
>> From: Mattias <mattias@kojin.tech>
>>
>>
>> kill-this-buffer is not working as before anymore.
>>
>> Old behaviour:
>>
>> e -Q
>> C-x 3
>> M-x kill-this-buffer
>>
>> would kill the current buffer and display only one frame
>>
>> e -Q
>> C-x 3
>> M-x kill-this-buffer
>>
>> Will raise an error:
>>
>> Debugger entered--Lisp error: (error "kill-this-buffer must be bound to
>> an event with parameters")
>> command-execute(kill-this-buffer record)
>> execute-extended-command(nil "kill-this-buffer" "kill-th")
>> funcall-interactively(execute-extended-command nil "kill-this-buffer"
>> "kill-th")
>> command-execute(execute-extended-command)
> This is the intended behavior, not a bug: this command must be invoked
> from a mouse event.

bug#71510: 30.0.50; kill-this-buffer must be bound to an event with parameters

[Eli Zaretskii]

> Date: Wed, 12 Jun 2024 14:51:48 +0200
> Cc: 71510@debbugs.gnu.org
> From: Mattias <mattias@kojin.tech>
> 
> Hi Eli,
> 
> Thanks for your answer. To make it clear, I don't pretend that it's a 
> bug, I just noticed that the previous behaviour is no longer maintained. 
> The doc associated to the function states that:
> 
>      When called in the minibuffer, get out of the minibuffer
>      using `abort-recursive-edit'.
> 
>      This command can be reliably invoked only from the menu bar,
>      otherwise it could decide to silently do nothing."
> 
> So it looks like now the behaviour is enforced but the error message is 
> a bit underwhelming and the error trace doesn't help to understand 
> what's happening.
> 
> Anyway, thanks a lot for your answer, I'll now use `kill-current-buffer`

I've now mentioned kill-current-buffer in the doc string, and I'm
therefore closing this bug.