RE: C-x C-v considered harmful

[Bob Rogers]

   From: "Drew Adams" <address@hidden>
   Date: Thu, 2 Jul 2009 20:19:45 -0700

   >    If a particular user has a problem finger-confusing
   >    `C-x v d' with `C-x C-v', then s?he can use a different key
   >    for one or the other. End of problem.
   >
   > End of problem, but only for that user.  (Like I said, I have
   > already done that in my own .emacs.)

   Oh, so you already changed the `C-x v' prefix?

No, I bound "C-x C-v" to nil.  (You said "for one or the other".)  But I
may remove it again if my patch (or something similar) is accepted.

   >    If many, many users have the same finger problem, then `C-x v d'
   >    should be moved to a different key for everyone. But please don't
   >    change the behavior of `find-alternate-file' just because 
   >    some other key can be confused with `C-x C-v'.
   > 
   > Moving just "C-x v d" without moving the other version 
   > control commands on that prefix does no good; the same thing ought
   > to happen with any other command on the "C-x v" prefix...

   Yes, of course. So change the prefix key from `C-x v'. That's all.

   If this is a general problem, then use a general solution . . .

I did better:  I proposed a *specific* solution to a general problem:
My patch based on Miles' suggestion attacks what I think of as the heart
of the problem, that find-alternate-file sometimes destroys buffers
without confirmation.  One could make a reasonable case that that is the
only issue here, because it is true regardless of keybindings.

   . . .

   Or do nothing at all. Perhaps this is a non-problem not even looking
   for a non-solution?

   Demonstration: Prefix `C-x v' for version control and `C-x C-v' as
   `find-alternate-file' have been hanging around together as best
   buddies for decades. Apparently, this extremely dangerous potential
   for "data lossage", "deleting megabytes of data" (soon to be
   terabytes no doubt) just has _not_ been much of a problem in
   practice.

Sarcasm notwithstanding, I will accept the part of your argument that it
hasn't been a problem in *previous* decades.  It currently became a
problem for me only in the last year, because that is when I started
using "C-x C-v d" in order to get selective multi-file commits and
diffs.  And I have been losing shell buffers ever since; it's only just
now that I figured out why.  Up until then, I was perfectly happy to
ignore the existence of find-alternate-file.  This *is* a new problem,
caused by a change in my usage patterns, and it seems that I am not
alone in being bitten by it.

   > Moving the whole VC prefix is likely to make many users
   > scream with pain.  (I certainly would.)

   I certainly wouldn't. Even back when I used the `C-x v' commands a
   lot. Not a big deal at all.

   `v' for that prefix key was no doubt picked simply because it was
   mnemonic for "version" - not a biggee. And, to listen to you,
   apparently insufficient thought was given to the potential danger of
   finger-confusion with `C-x C-v'. So choose a different prefix key,
   doing it right this time.

Another straw man; I think rebinding of any commands would be a poor
idea, and I only mentioned it in my initial post because it never
occurred to me to improve find-alternate-file's data lossage protection
(thank you, Miles and Kevin).

   On the other hand, `C-x C-v', like `C-x C-f', `C-x C-b', and `C-x
   C-c', was chosen primarily for being easy to type, the expectation
   being that users would use these commands a lot.

Hmm.  That reminds me.  I have sometimes typed "C-x C-v" when I meant to
type "C-x C-f", also leading to lossage.  Keep this up and you may make
an advocate of rebinding "C-x C-v" of me yet.  ;-}

   . . .

   > So I think moving keys at this point for any of these
   > well-established commands is a non-starter.

   Those well-established commands are certainly no more
   well-established than the behavior of `find-alternate-file'. Better
   to change an (essentially arbitrary) key binding than to change the
   _behavior of a command_ just because some key it is bound to might be
   confused with the key some other command is bound to.  Command
   behavior should come first, key bindings second. The other way lies
   madness.

This is a poor argument; command behavior has been changed in order to
avoid inadvertent lossage many times in the past.  I think that is good
policy.

   > But let me also turn this around:  Out of the last X times you can
   > remember using C-x C-v, how many of those invocations were in 
   > a non-file buffer?  In other words, how likely is it, really,
   > that you might be faced with a new prompt, and be forced to deal
   > with it?

   1. Personally? I use `C-x C-v' _all_ of the time to simultaneously
   (a) kill the current buffer - whatever its type (file or non-file)
   and (b) visit a file or Dired. All of the time.

Yes, but I asked for numbers -- even very crude ones -- and you give me
nothing to make me believe that you would actually be affected by this
change more than once in a great while.

   2. But this is not about my individual practice or yours. These
   similar key bindings, `C-x C-v' and `C-x v <whatever>', have
   coexisted peacefully for decades. There is _no_ general problem. If
   users had been losing megabytes of data over the last 30 years, we
   would have heard about it (and done something about it) long before
   now. Little is more certain than that.

You have said that before, and it is still irrelevant; as I said above,
this is a new problem.  Or, if you prefer, an old one made newly
relevant by the increased vc-dir functionality.

   Furthermore, your "coexisted peacefully for decades" statement is not
even true.  A little CVS archaology shows that find-alternate-file
checked only (buffer-modified-p) in revision 1.1 on 1991-07-19; it was
only in rev 1.192 on 1994-09-23 that RMS added the (buffer-file-name)
check.  (RMS, do you remember why?  The current file-save offer was only
added in 2002.)  So, prior to 1994, you were using a find-alternate-file
implementation that was substantially similar to what I am proposing.

   In fact, if the "history" argument is what floats your boat, how
about another alternative:

   6.  Query only if the old current buffer is a modified buffer,
       offering to save only for file buffers, and aborting the kill
       otherwise.  The behavior would change only for modified non-file
       buffers (which does include *shell* buffers, but not most temp
       buffers), and makes it similar to its behavior up to 1994.

How about it?

                                        -- Bob