bug#11268: Rgrep can get out of hand, so...

[Drew Adams]

> Maybe `C-x k' is a better key binding.  With a prefix key it could
> ask whether to kill the buffer's process, but not kill the buffer.

1. `C-x k' should be limited to buffers, of course.  Any prefix arg use should
have something to do with buffers (which your suggestion satisfies).

A disadvantage of your suggestion is that it sacrifices a prefix-key value even
when a buffer has no associated process.

That might be OK if there is a complementary use for buffers that do not have an
associated process.  In that case, (re)use the same prefix-arg value for
something else, specific to such non-process buffers.  Without that possibility,
your suggestion sounds like a waste of a prefix-arg value.

2. There are lots of other things that, like a process, can be associated with a
buffer (e.g., windows).  They too could be competing candidates for the use of a
prefix arg with `C-x k'.

For this reason (#2), and because there are other possible uses of a prefix arg
that are directly related to killing the _buffer_ itself, I think it wise not to
use `C-x k' to kill something associated with a buffer (its process, windows,
local variables,...).  IOW, save `C-x k' for killing buffers.

3. By way of example, this is what the prefix arg does for `C-x k' in Icicle
minor mode:

>0: only buffers visiting files are candidates

<0: only buffers associated with the selected frame are candidates

 0: only buffers that have the same mode as the current buffer are candidates

Something like that makes sense to me for `C-x k': Use the prefix arg to select
classes of buffers that can be completion candidates for killing.  Do not use it
to select other things to kill, even if they are associated with a buffer.

4. If we do decide to bind a key for killing a process it should not be a key
that is either (a) repeatable (by holding it down) or (b) super-easy to type.
Better to reserve such keys for commands that can take advantage of those
qualities.  In addition, we do not want users accidentally killing processes
because the key chosen is too easily hit.

5. If we bind a key for killing a process, I'd suggest that the command provide
for completion among candidate processes.  It is the process that is the target,
not its buffer or some other object, so it should be the process (its
name/identifier) that is offered for completion.

6. I have no opinion about whether we should bind a key globally for killing a
process.  Good keys are in limited supply.  But I agree with Stefan that it is
not always obvious which key to use to kill a given process.

Binding a global key might help in this regard.  But see #5: the process
associated with the current buffer could be the default value, but we should
provide completion for all processes and let the command kill any process
chosen.