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


View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76969 <at> debbugs.gnu.org
Subject: bug#76969: kill-buffer fails silently when a thread exists where it's current
Date: Thu, 13 Mar 2025 16:16:46 -0400
Dmitry Gutov <dmitry <at> gutov.dev> writes:
> On 13/03/2025 16:58, Eli Zaretskii wrote:
>>> 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).

Note that if you try kill a buffer which is the process-buffer of some
process:

- process-kill-buffer-query-function will query the user whether they
  want to proceed.

- If the user decides to proceed, then the process in that buffer will
  simply be killed with SIGHUP.

Perhaps we should do a similar thing for threads?

- Add a new kill-buffer-query-functions which checks if the buffer being
  killed is the current-buffer of any threads, and if so, queries the
  user if they want to proceed.

- If the user decides to proceed, then do something like killing the
  thread with SIGHUP.  Probably call thread-signal on the thread.  We'll
  still need to switch the thread's current-buffer to a new buffer,
  since the thread could choose to handle the signal and continue
  executing.




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.