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

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

[jidanni]

Rgrep can cause massive searches.

Killing its buffer won't stop it!

Also it should say what keys to kill it right there at the top.

Indeed, not even (describe-function (quote rgrep)) or (describe-function
(quote grep)) says how to kill a runaway [r]grep.

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

[Juri Linkov]

> Rgrep can cause massive searches.
>
> Killing its buffer won't stop it!
>
> Also it should say what keys to kill it right there at the top.
>
> Indeed, not even (describe-function (quote rgrep)) or (describe-function
> (quote grep)) says how to kill a runaway [r]grep.

You can kill the running grep with `C-c C-k'.

Also when you kill its buffer with `C-x k',
it asks you the question:

  "Buffer "*grep*" has a running process; kill it? (yes or no)"

Just say yes.

If you can't find the buffer where grep runs, use
`M-x list-processes RET' to find the ruinning process.

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

[jidanni]

JL> You can kill the running grep with `C-c C-k'.
OK that worked this time...
Well at least the docstrings should mention that.

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

[Chong Yidong]

jidanni@jidanni.org writes:

> Well at least the docstrings should mention that.

Fair enough; added.

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

[Stefan Monnier]

>> Well at least the docstrings should mention that.
> Fair enough; added.

Reminds me that I think we should have a global key binding for "kill
the current buffer's process" (which should also work to kill a process
which is conceptually linked to the current buffer but runs in another
hidden buffer, as in the case of *vc-dir*): the rare times that I need
to kill a process, I need to do it ASAP and I always find myself
scrambling around, trying out madly the few key-bindings that come to my
fingers (among which C-c C-c seems like a natural fit, according to my
fingers, although I usually prefer to associate it to things like
`compile', or `send').


        Stefan

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

[jidanni]

Never ever use two of the same key, e.g., C-c C-c, without
confirmation.

It's not going to cooperate if it is busy anyway, so
I always end up starting a new shell to do killall emacs.

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

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> Well at least the docstrings should mention that.
>> Fair enough; added.
>
> Reminds me that I think we should have a global key binding for "kill
> the current buffer's process"

C-c C-k

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Reminds me that I think we should have a global key binding for "kill
>> the current buffer's process"
>
> C-c C-k

That's bound to `message-kill-buffer' in Message mode, and I vaguely
remember that I copied that meaning for the keystroke from somewhere
else...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Juri Linkov]

>>> Reminds me that I think we should have a global key binding for "kill
>>> the current buffer's process"
>>
>> C-c C-k
>
> That's bound to `message-kill-buffer' in Message mode, and I vaguely
> remember that I copied that meaning for the keystroke from somewhere
> else...

Other modes use it for other meanings like `show-branches' in outline.

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.

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.

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

[Stefan Monnier]

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

I could live with a command that requires interaction, but I'd then
override it in my Emacs because when I need this feature, I'm usually in
a real hurry to kill it (as in "no!! I didn't mean that!!") and have no
time for minibuffer completion/selection.


        Stefan

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

[Drew Adams]

> > 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.
> 
> I could live with a command that requires interaction, but I'd then
> override it in my Emacs because when I need this feature, I'm 
> usually in a real hurry to kill it (as in "no!! I didn't mean that!!") 
> and have no time for minibuffer completion/selection.

I understand.

(Of course, you only have to hit RET to accept the default of the current
buffer's process.  Still, sometimes a keystroke matters.)