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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
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 23:21:59 +0200

On 13/03/2025 22:29, Eli Zaretskii wrote:

>> 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?

Yeah, I think a timer or a sentinel killing a non-"private" buffer would 
be a programmer error. Still, in that case the caller can compare the 
kill-buffer argument to current-buffer and see that they're equal - so 
print-debugging would still work (or edebug, etc).

>>>> 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.

Okay, how about Spencer's suggestion (maybe modulo the 
kill-buffer-query-functions part)? When we try to kill a buffer that is 
current to a thread, we first send a signal to that thread (to be 
handled async), then switch that thread's buffer to another (*). Do that 
check in all threads, then kill the buffer.

This way the Lisp code running in there would be notified about the 
change - and probably crash right away unless it expects this specific 
error. Better than a silent change.

(*) Though we should probably do that after and if all 
kill-buffer-query-functions have run with positive result.

Previous Next

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