GNU bug report logs - #76969
kill-buffer fails silently when a thread exists where it's current

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dmitry <at> gutov.dev>

Date: Wed, 12 Mar 2025 01:17:01 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76969 <at> debbugs.gnu.org
Subject: bug#76969: kill-buffer fails silently when a thread exists where it's current
Date: Thu, 13 Mar 2025 14:10:36 +0200
On 13/03/2025 11:47, Eli Zaretskii wrote:

>> Expected:
>>
>> It probably should be killed. After the thread is signaled some error
>> (perhaps) and is aborted. And if the buffer can't be killed,
>> 'kill-buffer' itself should exit with an error.
>>
>> As I understand the behavior is old (2013) and comes from the
>> 'thread_check_current_buffer' call in Fkill_buffer. But it's not
>> mentioned in kill-buffer's docstring or the manual.
> 
> There are other reasons which preclude killing a buffer that aren't
> mentioned in the doc string.  For example, this:

That's a good point.

>    /* Don't kill the minibuffer now current.  */
>    if (BASE_EQ (buffer, XWINDOW (minibuf_window)->contents))
>      return Qnil;
> 
> or this:
> 
>    /* Make this buffer not be current.  Exit if it is the sole visible
>       buffer.  */
>    if (b == current_buffer)
>      {
>        tem = Fother_buffer (buffer, Qnil, Qnil);
>        Fset_buffer (tem);
>        if (b == current_buffer)
> 	return Qnil;
> 
> or this:
> 
>    /* If the buffer now current is shown in the minibuffer and our buffer
>       is the sole other buffer give up.  */
>    XSETBUFFER (tem, current_buffer);
>    if (EQ (tem, XWINDOW (minibuf_window)->contents)
>        && BASE_EQ (buffer, Fother_buffer (buffer, Qnil, Qnil)))
>      return Qnil;
> 
> So if this is a request to spell out these conditions in the
> documentation, I'm okay with doing so.

Yes, I think it will be good to note that there are certain rare 
exceptions (when the buffer is the minibuffer or the sole other buffer), 
and that kill-buffer will skip killing them and simply return nil 
without complaint.

> But is this the only request
> here?  If not, please elaborate.

The situation with threads seems different because it can affect, 
potentially, (almost) any Lisp code and almost any buffer that a Lisp 
program expects to kill. The more often threads are used, the higher the 
odds will be.

And the consequences seem less severe, conceptually, than killing one of 
the exceptions mentioned above. The exception for threads seems to have 
been made as a matter of implementation convenience, so it's worth 
revisiting.

To reiterate, having the buffer killed (and the associated thread with 
it) seems preferable - perhaps after allowing the thread to handle the 
attempt. And/or if the killing does not happen, showing a warning or an 
error would be an improvement.




This bug report was last modified 93 days ago.

Previous Next


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