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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 22 Jul 2025 02:50:44 +0300

On 18/07/2025 09:24, Eli Zaretskii wrote:
>> Date: Fri, 18 Jul 2025 03:23:43 +0300
>> Cc: [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>>    . I think we should add an optional argument to make-thread, because
>>>      calling a function to change the buffer_killable_p attribute might
>>>      be too late (I'm not against having the function as well)
>>
>> Do you think there is a chance for the thread to be started between the
>> 'make-thread' and 'thread-set-buffer-killable' calls, even if they go
>> one after another?
> 
> No.  But it makes no sense to provide a separate interface if it must
> always be called immediately after make-thread, or else should be
> expected to be unreliable.
> 
>> I considered making it a keyword argument of 'make-thread' but it seems
>> like it might not interest most callers, and so clutter the definition
>> (I couldn't come up with a less awkward name either). Not a strong
>> opinion, though.
> 
> There's no need for keyword arguments.  make-thread has just 2
> arguments as of now; adding one more is not going to make the calls
> awkward, especially if most callers will never pass that additional
> argument.

All right.

So if we make it an optional argument of 'make-thread', and the default 
is for thread's buffer to be killable, that might call for a name change 
(flipping the meaning).

Should it be

   (make-thread FUNCTION &optional NAME BUFFER-PROTECTED)

?

With default nil and other possible values 't' and 'kill-silently'.