emacs-devel
[Top][All Lists]
Advanced

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

RE: C-x C-v considered harmful


From: Bob Rogers
Subject: RE: C-x C-v considered harmful
Date: Thu, 2 Jul 2009 21:09:16 -0400

   From: "Drew Adams" <address@hidden>
   Date: Thu, 2 Jul 2009 08:17:59 -0700

   Problem statement:

   >>>> I often invoke vc-dir in the *shell* buffer,...
   >>>> but sometimes type "C-x C-v d RET" instead...
   >>>> I haven't let go of the Ctrl key fast enough.

   Proposed solutions:

   > > How  about:
   > >   4.  Make find-alternate-file use a yes-or-no-p 
   > >   confirmation prompt if the buffer has no associated file.
   > >   My guess is that the vast  majority of uses of
   > >   find-alternate-file are replacing one file buffer with
   > >   another, and that intentionally replacing "special"
   > >   buffers is very rare.

   > 5. Make find-alternate-file use a yes-or-no-p confirmation 
   > prompt if the buffer has an associated process.  This would
   > cover *shell* buffers.

I would be happier with a broader solution -- it's not only *shell*
buffers that I might miss if they were to disappear unexpectedly.
(Personally, I don't usually invoke VC commands in other non-file
buffers, but others might, and I don't see the need to discriminate.)

   This is like saying that we should change the behavior of `C-x C-f'
   so that it asks for confirmation, because if you don't release the
   Control key fast enough you get `C-x f', which sets the fill
   column. Or similarly, for `C-x C-b' or `C-x C-c' or `C-x C-d' or ...
   There are tons of key combinations that exhibit the same "problem".

I won't challenge your hyperbole, but the argument as a whole is a straw
man.  How many of those key combinations lend themselves to typos that
are capable of deleting megabytes of data -- without confirmation?

   I disagree with all of the above "solutions". The problem is not the
   behavior of `find-alternate-file' or its binding to `C-x C-v'. If
   there really is a problem, it is the too-similar binding of `C-x v d'.

   `C-x C-v' is much older than `C-x v d', and my guess is that it is
   still more widely used . . .

More widely used?  Really?

   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.)  It's the people who haven't been bitten by
it yet that I'm trying to help here.

   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 that has a minibuffer prompt when
you take the default sight unseen.  Moving the whole VC prefix is likely
to make many users scream with pain.  (I certainly would.)  So I think
moving keys at this point for any of these well-established commands is
a non-starter.

   Of the "solutions" mentioned above to the "problem", #5 from Kevin R
   is preferable, being the least restrictive on the behavior of
   `find-alternate-file'. But there should be no reason to restrict its
   behavior at all.

Is preventing data lossage not a goal for you?  Seems to me there have
been lots of prompts added over the decades in order to avoid potential
lossage of similar nature.  And we're talking about a whole *buffer* in
this case.  Even find-alternate-file already has a prompt to avoid
losing changes to a modified file buffer.  Why do you see a problem with
broadening this to cover other lossage?

   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?

                                        -- Bob




reply via email to

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