all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Bob Rogers'" <rogers-emacs@rgrjr.dyndns.org>
Cc: 'Kevin Rodgers' <kevin.d.rodgers@gmail.com>, emacs-devel@gnu.org
Subject: RE: C-x C-v considered harmful
Date: Thu, 2 Jul 2009 20:19:45 -0700	[thread overview]
Message-ID: <F55339BC4AA04BA1BFCC5CF6AFBEDB04@us.oracle.com> (raw)
In-Reply-To: <19021.23100.86775.844823@rgr.rgrjr.com>

>    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'.
>
>    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? Why didn't you instead redefine
`find-alternate-file'? Which prefix key did you choose? Perhaps Emacs should do
the same as you? 

>    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. Pick a prefix key
that won't easily be confused with something that might kill your *shell* (or
whatever) buffer with your megabytes of unsaved data.

Use `C-x c' ("change control"; `C-x C-c' already warns about losing unsaved
stuff and terminating running processes). Use `C-x g'. Use `C-x p'. Use `C-x t'.
Use `C-x w'. Use `C-x x'. Use `C-x y'. Or use prefix `C-x V'... Or venture
beyond `C-x'...

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.

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

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.

These are among the most basic Emacs keys/commands, all created on Day 1 of the
Holy Big Emacs Bang. The version-control stuff came long after Day 7's Rest,
when the Grand Gnu realized She might need to back up occasionally and do some
stuff over again differently.

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

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

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.

3. And if you were to somehow demonstrate that a general problem has suddenly
surfaced, then the solution is not to change the behavior of a command as
well-established as `find-alternate-file'. The solution is to change the
version-control prefix key.





  reply	other threads:[~2009-07-03  3:19 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 [this message]
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
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=F55339BC4AA04BA1BFCC5CF6AFBEDB04@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=kevin.d.rodgers@gmail.com \
    --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.