When explicitly killing a shell/eshell or terminal-emulator ansi-term/term buffer, a user shouldn't have to take an extra step to respond to the prompt of process-kill-buffer-query-function. In such cases, the process for which function process-kill-buffer-query-function is activated is the foreground shell process, so of course the conscious user intent is to kill it. One way to implement this is to have the mode entry functions remove the entry from the buffer-local copy of kill-buffer-query-functions (if that's an option for that variable). Another possibility is to put the logic inside function process-kill-buffer-query-function. There may be other ways. I'm not sure which is preferable so I haven't included a patch. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
> Date: Mon, 12 Oct 2020 10:07:14 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
>
> When explicitly killing a shell/eshell or terminal-emulator
> ansi-term/term buffer, a user shouldn't have to take an extra step to
> respond to the prompt of process-kill-buffer-query-function. In such
> cases, the process for which function process-kill-buffer-query-function
> is activated is the foreground shell process, so of course the conscious
> user intent is to kill it.
FWIW, I'm not sure an unconditional change in behavior here is TRT.
Killing a buffer doesn't necessarily imply the user is aware that the
process will be killed as well.
I wouldn't object to an opt-in option, though.
Eli Zaretskii <eliz@gnu.org> writes: >> When explicitly killing a shell/eshell or terminal-emulator >> ansi-term/term buffer, a user shouldn't have to take an extra step to >> respond to the prompt of process-kill-buffer-query-function. In such >> cases, the process for which function process-kill-buffer-query-function >> is activated is the foreground shell process, so of course the conscious >> user intent is to kill it. > > FWIW, I'm not sure an unconditional change in behavior here is TRT. > Killing a buffer doesn't necessarily imply the user is aware that the > process will be killed as well. Indeed. I for one would find an unconditional change here highly unsettling. I often have a bunch of processes running in the background and can't be bothered to remember which is running in which buffer. Getting prompted is important so I don't lose any work. > I wouldn't object to an opt-in option, though. Agreed.
Eli Zaretskii <eliz@gnu.org> writes: > FWIW, I'm not sure an unconditional change in behavior here is TRT. > Killing a buffer doesn't necessarily imply the user is aware that the > process will be killed as well. > > I wouldn't object to an opt-in option, though. I think this sounds a bit obscure as a user option, to be honest. We already have options covering customisations here. For instance, if there's certain process connections a user doesn't care about, they can write hook functions to set `set-process-query-on-exit-flag' for those processes. And for this specific change -- to not ask about the process in the current buffer when issuing the `C-x C-c' command -- I think the user could easily write a three line function and put that in `kill-buffer-query-function' instead of `process-kill-buffer-query-function'. That is, I feel the range of things a user could want to have happen in this case is so wide that adding a single `don't-query-about-the-process-in-the-current-buffer' variable would not significantly help a large enough group of users. So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no