bug#43957: remove process-kill-buffer-query-function from kill-buffer-query-functions

bug#43957: remove process-kill-buffer-query-function from kill-buffer-query-functions

[Boruch Baum]

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

bug#43957: remove process-kill-buffer-query-function from kill-buffer-query-functions

[Eli Zaretskii]

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

bug#43957: remove process-kill-buffer-query-function from kill-buffer-query-functions

[Stefan Kangas]

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.

bug#43957: remove process-kill-buffer-query-function from kill-buffer-query-functions

[Lars Ingebrigtsen]

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