unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>,
	"'Lars Magne Ingebrigtsen'" <larsi@gnus.org>
Cc: 11268@debbugs.gnu.org, 'Chong Yidong' <cyd@gnu.org>,
	'Andreas Schwab' <schwab@linux-m68k.org>
Subject: bug#11268: Rgrep can get out of hand, so...
Date: Thu, 19 Apr 2012 09:28:31 -0700	[thread overview]
Message-ID: <54C6D7B33A2F4E42B24EDCE1985FEDED@us.oracle.com> (raw)
In-Reply-To: <87r4vjaj8x.fsf@mail.jurta.org>

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






  reply	other threads:[~2012-04-19 16:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 22:24 bug#11268: Rgrep can get out of hand, so jidanni
2012-04-18  5:28 ` Juri Linkov
2012-04-18  5:49 ` jidanni
2012-04-18  6:03   ` Chong Yidong
2012-04-19  7:51     ` Stefan Monnier
2012-04-19  8:08       ` jidanni
2012-04-19  8:28       ` Andreas Schwab
2012-04-19 10:29         ` Lars Magne Ingebrigtsen
2012-04-19 14:28           ` Juri Linkov
2012-04-19 16:28             ` Drew Adams [this message]
2012-04-19 22:25               ` Stefan Monnier
2012-04-19 23:22                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54C6D7B33A2F4E42B24EDCE1985FEDED@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11268@debbugs.gnu.org \
    --cc=cyd@gnu.org \
    --cc=juri@jurta.org \
    --cc=larsi@gnus.org \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).