[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C-x C-v considered harmful

From: Juri Linkov
Subject: Re: C-x C-v considered harmful
Date: Tue, 07 Jul 2009 02:49:00 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu)

>     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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]