all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
To: rms@gnu.org
Cc: rogers-emacs@rgrjr.dyndns.org, Drew Adams <drew.adams@oracle.com>,
	emacs-devel@gnu.org
Subject: Re: C-x C-v considered harmful
Date: Tue, 07 Jul 2009 02:49:00 +0300	[thread overview]
Message-ID: <87vdm5xqpv.fsf@mail.jurta.org> (raw)
In-Reply-To: <E1MNFEp-0006a6-00@fencepost.gnu.org> (Richard Stallman's message of "Sat, 04 Jul 2009 20:05:47 -0400")

>     Fully half the reason I use `find-alternate-file' is to _kill_ the current
>     buffer (mistaken file visit or not). I use `C-x C-f' when I want to keep the
>     current buffer, and `C-x C-v' when I want to kill it. I wouldn't have thought I
>     was alone in that, but I'm beginning to get the impression that I might be.
>
> Of course, getting rid of the current buffer is why one uses it.  The
> question is whether it is sufficienty easier than C-x C-k RET and M-p
> to justify giving it a key binding.

I'd like to add one more use case of C-x C-v.  I use ffap that allows
C-x C-v to grab an absolute file name from the current buffer to
the minibuffer.  For example, one scenario is the following:

  M-x shell RET

  dpkg -L debian-package RET

This command outputs a list of absolute file names in the *shell* buffer.

  C-p C-p C-p ... C-x C-v RET

After moving point to the necessary absolute file name, C-x C-v
puts the file name to the minibuffer and RET just visits it.
I don't need to preserve the *shell* buffer after that.

However, maybe I would tolerate an yes-no confirmation in the *shell*
buffer since I more often use M-! for the same purposes.

Of course, this raises a question whether an information's worth in the
*shell* buffer is higher than in the *Shell Command Output* buffer
and shouldn't killing the *Shell Command Output* buffer ask a confirmation
as well?

Then what about the Async shell command that runs a command in the background?
Should C-x C-v ask a confirmation in the *Async Shell Command* buffer?
Currently it simply kills the child process without a question.

BTW, I am experiencing a higher risk of losing information with M-!
more than with C-x C-v.  M-! is difficult to type with one hand
because the `1' key is located directly above the Shift key,
so a combination with the Meta key often produces the wrong key M-1
(with Shift unpressed).  Typing a shell command in a Dired buffer
without paying attention to the screen results in a complete mess
(since most Dired keybndings are just one letter) that needs to be
analyzed afterwards to determine the damage (looking for files marked,
copied, moved, deleted, etc.)

-- 
Juri Linkov
http://www.jurta.org/emacs/




  parent reply	other threads:[~2009-07-06 23:49 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-02  1:18 C-x C-v considered harmful Bob Rogers
2009-07-02  2:39 ` Miles Bader
2009-07-02  3:10   ` Bob Rogers
2009-07-02  6:48   ` Kevin Rodgers
2009-07-02 15:17     ` Drew Adams
2009-07-03  1:09       ` Bob Rogers
2009-07-03  3:19         ` Drew Adams
2009-07-03 20:33           ` Bob Rogers
2009-07-03 22:23             ` Drew Adams
2009-07-04 23:16               ` Bob Rogers
2009-07-05  7:13                 ` Drew Adams
2009-07-06  0:39                   ` Bob Rogers
2009-07-06  1:40                     ` Drew Adams
2009-07-07 10:39                       ` Johan Bockgård
2009-07-05 10:18                 ` Richard Stallman
2009-07-05 14:56                   ` Drew Adams
2009-07-05  0:05               ` Richard Stallman
2009-07-05  7:10                 ` Drew Adams
2009-07-06 15:05                   ` Richard Stallman
2009-07-06 15:59                     ` Drew Adams
2009-07-07 10:05                       ` Richard Stallman
2009-07-06 12:04                 ` Robert J. Chassell
2009-07-06 23:49                 ` Juri Linkov [this message]
2009-07-07  1:07                   ` Drew Adams
2009-07-08  0:32                     ` Juri Linkov
2009-07-08 23:28                       ` Juri Linkov
2009-07-09 16:09                         ` Drew Adams
2009-07-09 22:10                           ` Juri Linkov
2009-07-09 22:26                             ` Drew Adams
2009-07-09 22:46                               ` Juri Linkov
2009-07-09 23:21                                 ` Drew Adams
2009-07-10  4:05                                   ` Bob Rogers
2009-07-13 20:05                         ` Juri Linkov
2009-07-16 21:57                           ` Juri Linkov
2009-07-03  2:40       ` M Jared Finder
2009-07-03  2:57         ` Miles Bader
2009-07-03 19:23         ` Richard Stallman
2009-07-03 20:07           ` Andreas Schwab
2009-07-03 20:56           ` Miles Bader
2009-07-03 13:55     ` Markus Triska
2009-07-05 22:15       ` Stefan Monnier
2009-07-05 22:42         ` Bob Rogers
2009-07-11 10:06           ` Stefan Monnier
2009-07-14  2:45             ` Bob Rogers
2009-07-14 18:34               ` Stefan Monnier
2009-07-02 21:03 ` Stefan Monnier

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

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

  git send-email \
    --in-reply-to=87vdm5xqpv.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=rogers-emacs@rgrjr.dyndns.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.