Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where it's current

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Mar 2025 22:29:55 +0200

> Date: Thu, 13 Mar 2025 21:30:15 +0200
> Cc: [email-masked], Spencer Baugh <[email-masked]>
> From: Dmitry Gutov <[email-masked]>
> 
> On 13/03/2025 16:58, Eli Zaretskii wrote:
> 
> > If we want to kill a buffer that is the current buffer of some thread,
> > we must do the same thing we do when killing the buffer that is
> > current in the thread which calls kill-buffer: replace it with some
> > other buffer, if possible:
> > 
> >    /* 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;
> >      }
> 
> Makes sense, but it's probably not a good idea for threads. Same reason: 
> unpredictability.
> 
> If the direct kill-buffer call swaps the buffer under you, it's somewhat 
> odd, but at least it's predictable and can be debugged. Having a 
> different thread do that do your execution flow at a random time is 
> quite another thing.

Suppose a process filter or sentinel, or a timer does that -- is that
any different? should we forbid that?

> >> And/or if the killing does not happen, showing a warning or an error
> >> would be an improvement.
> > 
> > We could signal an error, yes.  But it sounds too drastic to me.
> 
> Or a warning, or an entry in *Messages*, at least. Anything's better 
> than silent noop. And you can't examine the thread's current buffer in 
> Lisp, to find the conflicting thread another way from Lisp (e.g. for 
> print-debugging).

I'd still prefer to kill the buffer, just more safely.  I mean, how is
this different from killing a buffer that is displayed in one or more
windows?  We do handle that.