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

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 76969 <at> debbugs.gnu.org
Subject: Re: bug#76969: kill-buffer fails silently when a thread exists where
 it's current
Date: Thu, 13 Mar 2025 22:29:55 +0200
> Date: Thu, 13 Mar 2025 21:30:15 +0200
> Cc: 76969 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> 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.




This bug report was last modified 1 day ago.

Previous Next


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