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

[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`

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.