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


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 93 days ago.

Previous Next


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