C-x C-v considered harmful

[Bob Rogers]

   I have finally discovered what has been making my *shell* buffers
disappear mysteriously from time to time.  It's because I often invoke
vc-dir in the *shell* buffer, in order to take the directory default
from there, but sometimes type "C-x C-v d RET" instead -- too quickly to
realize that I haven't let go of the Ctrl key fast enough.  So instead
of vc-dir, I end up in an empty buffer named "d", and *shell* is gone
for good.  IMHO, the "C-x C-v" binding to find-alternate-file makes it
much too easy to typo oneself into information loss.

   Possible solutions:

   1.  Bind find-alternate-file to something different.  (Probably too
late for that.)

   2.  Add a "[Confirm]" step if nonexistent, as for selecting files or
buffers with confirm-nonexistent-file-or-buffer set to t.  (Oops; that's
probably too controversial.)

   3.  Do not bind find-alternate-file to anything at all.

   I've adopted the third solution locally, so I will not kick up a fuss
if people want to keep the status quo.  But I think it's much less user-
hostile to let those who are knowledgeable enough to want the feature
enable it for themselves, than to let buffers to disappear mysteriously
on the unwary.

                                        -- Bob Rogers
                                           http://www.rgrjr.com/

[Miles Bader-2]

Bob Rogers <rogers-emacs@...> writes:
>    1.  Bind find-alternate-file to something different.  
>    2.  Add a "[Confirm]" step if nonexistent, as for selecting files or
> buffers with confirm-nonexistent-file-or-buffer set to t.
>    3.  Do not bind find-alternate-file to anything at all.

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.

       If there are specific modes or buffers for which "replacement"
       _is_ commonly used, then there could be a variable to tell
       find-alternate-file not to confirm that buffer (and a user could
       set the global default value of that variable to turn off all
       confirmation)

-Miles

--
Monday, n. In Christian countries, the day after the baseball game.

[Bob Rogers]

   From: Miles Bader <miles@...>
   Date: Thu, 02 Jul 2009 11:39:17 +0900

   Bob Rogers <rogers-emacs@...> writes:
   >    1.  Bind find-alternate-file to something different.  
   >    2.  Add a "[Confirm]" step if nonexistent, as for selecting files or
   > buffers with confirm-nonexistent-file-or-buffer set to t.
   >    3.  Do not bind find-alternate-file to anything at all.

   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.

Agreed; I like this best.  Please find a patch below that broadens the
case for modified files to cover non-files as well.

          If there are specific modes or buffers for which "replacement"
          _is_ commonly used, then there could be a variable to tell
          find-alternate-file not to confirm that buffer (and a user could
          set the global default value of that variable to turn off all
          confirmation)

   -Miles

Here is the way find-alternate-file describes itself:

    Find file FILENAME, select its buffer, kill previous buffer.  If the
    current buffer now contains an empty file that you just visited
    (presumably by mistake), use this command to visit the file you
    really want.

Given this perspective, the replace-a-non-file-buffer use case would
seem to be rare -- and always asking about non-file buffers makes sense.

                                        -- Bob

------------------------------------------------------------------------
Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1052
diff -c -r1.1052 files.el
*** lisp/files.el 22 Jun 2009 07:02:08 -0000 1.1052
--- lisp/files.el 2 Jul 2009 03:02:48 -0000
***************
*** 1465,1471 ****
    t)))
    (unless (run-hook-with-args-until-failure 'kill-buffer-query-functions)
      (error "Aborted"))
!   (when (and (buffer-modified-p) (buffer-file-name))
      (if (yes-or-no-p (format "Buffer %s is modified; kill anyway? "
      (buffer-name)))
  (unless (yes-or-no-p "Kill and replace the buffer without saving it? ")
--- 1465,1472 ----
    t)))
    (unless (run-hook-with-args-until-failure 'kill-buffer-query-functions)
      (error "Aborted"))
!   (when (or (not (buffer-file-name))
!    (buffer-modified-p))
      (if (yes-or-no-p (format "Buffer %s is modified; kill anyway? "
      (buffer-name)))
  (unless (yes-or-no-p "Kill and replace the buffer without saving it? ")

[Kevin Rodgers-2]

Miles Bader wrote:

> Bob Rogers <rogers-emacs@...> writes:
>>    1.  Bind find-alternate-file to something different.  
>>    2.  Add a "[Confirm]" step if nonexistent, as for selecting files or
>> buffers with confirm-nonexistent-file-or-buffer set to t.
>>    3.  Do not bind find-alternate-file to anything at all.
>
> 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.
>
>        If there are specific modes or buffers for which "replacement"
>        _is_ commonly used, then there could be a variable to tell
>        find-alternate-file not to confirm that buffer (and a user could
>        set the global default value of that variable to turn off all
>        confirmation)

The specific mode that leaps to mind is Dired.  I often use C-x C-v in
Dired buffers to visit a different directory, just as I do in file
buffers.  So how about:

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.

--
Kevin Rodgers
Denver, Colorado, USA

[Drew Adams]

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:

> >>    1.  Bind find-alternate-file to something different.  
> >>    2.  Add a "[Confirm]" step if nonexistent, as for
> >>    selecting files or buffers with
> >>    confirm-nonexistent-file-or-buffer set to t.
> >>    3.  Do not bind find-alternate-file to anything at all.
> >
> > 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.
> >
> >   If there are specific modes or buffers for which "replacement"
> >   _is_ commonly used, then there could be a variable to tell
> >   find-alternate-file not to confirm that buffer (and
> >   a user could set the global default value of that variable
> >   to turn off all confirmation)
>
> The specific mode that leaps to mind is Dired.  I often use C-x C-v in
> Dired buffers to visit a different directory, just as I do in file
> buffers.  So how about:
>
> 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.

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 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. And `C-x v d' has narrower focus, being specific to the context of
change control.

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.

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

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.

Fix `C-x v d', if you feel you must, but leave `find-alternate-file' alone. It's
been just fine for a third of a century, thank you. It should not be forced to
move or change its behavior just because a newcomer to the neighborhood chooses
a similar phone #.

[Stefan Monnier]

> from there, but sometimes type "C-x C-v d RET" instead -- too quickly to
[...]
>    2.  Add a "[Confirm]" step if nonexistent, as for selecting files or
> buffers with confirm-nonexistent-file-or-buffer set to t.  (Oops; that's
> probably too controversial.)

Actually, I think it's a bug that C-x C-v doesn't obey
confirm-nonexistent-file-or-buffer.


        Stefan

[Bob Rogers]

   From: "Drew Adams" <drew.adams@...>
   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

[M Jared Finder]

Drew Adams wrote:

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

As a relatively new user of Emacs (about five years), I have *NEVER*
used find-alternate-file, and after reading its description, the
keystroke savings seems so minor that I can not imagine ever wanting to.
  Is C-x C-v really so much better than C-x k <RET> C-x C-f?

There's already a mechanism in Emacs to disable old, clunky commands
than most people don't use and can be harmful, (put SYMBOL 'disabled t).
    Why not just disable this command?

   -- MJF

[Miles Bader-2]

M Jared Finder <jared@...> writes:
> As a relatively new user of Emacs (about five years), I have *NEVER*
> used find-alternate-file, and after reading its description, the
> keystroke savings seems so minor that I can not imagine ever wanting
> to. Is C-x C-v really so much better than C-x k <RET> C-x C-f?

Yes, it's actually quite useful in some cases, and I find I use it
regularly, typically when I've accidentally visited the wrong file -- it
automatically fills in the minibuffer with the old name, so it's usually
very quick to correct the name and hit RET.

[I bind it a different key tho -- C-x C-r (for "read file")]

-Miles

--
Saa, shall we dance?  (from a dance-class advertisement)

[Drew Adams]

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

[Markus Triska-2]

Kevin Rodgers <kevin.d.rodgers@...> writes:

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

I agree completely with Bob that C-x C-v should be made safer. I use it
very frequently and have also accidentally lost data by using it. Your
suggestion of making it dependent on an associated process sounds very
good, but unfortunately it doesn't work for example with ERC buffers.

[Richard Stallman]

    keystroke savings seems so minor that I can not imagine ever wanting to.
      Is C-x C-v really so much better than C-x k <RET> C-x C-f?

The case where it gave an advantage is that you can enter the
corrected file name based on the mistaken one, rather than starting
from scratch.

But that is not much of an advantage nowadays, because you can get the
mistaken file name via the minibuffer history.

So maybe C-x C-v should be disabled and/or eliminated.  But that is
the sort of thing for which the maintainers should poll the users,
rather than just decide on their own.

Miles says

    Yes, it's actually quite useful in some cases, and I find I use it
    regularly, typically when I've accidentally visited the wrong file -- it
    automatically fills in the minibuffer with the old name, so it's usually
    very quick to correct the name and hit RET.

Miles, if you had to type
C-x k RET C-x C-f M-p instead of C-x C-v,
in those cases, how painful would that be?

[Andreas Schwab-2]

Richard Stallman <rms@...> writes:

> C-x k RET C-x C-f M-p instead of C-x C-v,

Another difference is that M-p places point at the end, whereas C-x C-v
places it after the directory component.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Bob Rogers]

   From: "Drew Adams" <drew.adams@...>
   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

[Miles Bader-2]

Richard Stallman <rms@...> writes:
> Miles, if you had to type
> C-x k RET C-x C-f M-p instead of C-x C-v,
> in those cases, how painful would that be?

It would be a bit more annoying of course, but it's very hard to
estimate how much.  I'd probably live.

Of course, since I rebind find-file and find-alternate-file anyway, I'd
be perfectly happy if there were no default binding for f-a-f.

Arguably the longer command, being a composition of more primitive
concepts, is better for making Emacs "explainable"...

*however* even there were no default binding for f-a-f, I'd probably
 want to keep my personal binding, and I _do_ occasionally inadvertently
 destroy non-file buffers with f-a-f ... so I think the suggested change
 to f-a-f (to confirm on non-file buffers) is still useful.

-Miles

--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

[Drew Adams]

> you may make an advocate of rebinding "C-x C-v" of me yet.  ;-}

I would sooner see a key-binding change for either `find-alternate-file' or the
vc stuff than I would see an unnecessary modification of the command behavior.
If key-binding confusion is the problem, then the solution is a key-binding
change. If, on the other hand, the command `find-alternate-file' is itself
inherently dangerous, then yes, the command behavior should be altered.

It's best to separate the concerns when analyzing the problem you ran into:
consider both (a) the command behavior and (b) the key bindings. Whatever the
binding, is `find-alternate-file' dangerous? If so, then let's fix its behavior.
If not, then if there is a problem caused by key-binding confusion, then change
one of the two bindings that people (fingers) confuse.

To be clear, I don't have a big problem with changing the binding of
`find-alternate-file', assuming the new binding is not something far-fetched. I
do think it's important to have a relatively easy-to-use and easily discovered
binding for this, because I consider the command useful. Apparently, some users
who might be taking advantage of it have never learned that it exists. That's
too bad.

And I don't agree with Richard that having a history list obviates the
usefulness of `find-alternate-file':

R> But that is not much of an advantage nowadays, because you can
R> get the mistaken file name via the minibuffer history.

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.

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

"_All_ of the time" does not suggest "once in a great while" - at least that was
not my intention in using those words.

If I had to guess a number, I'd guess between X/3 and X/2. FWIW, that's the same
guess I'd make for the buffers I use in general: maybe 2/3 are file buffers.
Just a guess. I do not use `C-x C-v' any more or any less depending on the type
of buffer to be killed, as I already stated.

(Yes, when switching from a file buffer, `find-alternate-file' presents an
additional advantage, since the file to be visited is typically in the same
directory and sometimes has a similar file name. But that is an advantage
relative to other ways to visit a file (e.g. `C-x C-f'); it is not an advantage
relative to switching from a non-file buffer.)

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

Yes, but I think I would prefer `(or buffer-read-only (buffer-modified-p))'.

Killing read-only buffers such as Dired and *Buffer List* that might be modified
(e.g. markings) should not bother one by querying. That would likely be my
preference, but I can see that it might be debatable. It all depends where one
stands on the danger-vs-reminder-annoyance spectrum. I don't have a problem with
`find-alternate-file' never querying me more than would `C-x k', but some others
might.

I have the feeling that the noble motive of protecting from data loss is perhaps
being sidetracked here. To me, this is, or should be, about what happens when
you ask to kill a given buffer - regardless of how you ask that. Whether you use
`C-x k' or `C-x C-v', the buffer to be killed (or the killing operation) should
take care of warning you and giving you a change to change your mind, whenever
that is appropriate.

That is, the _same_ warning/querying behavior is called for, regardless of how
you attempt to kill the buffer (interactively). And the behavior that is
appropriate depends on the buffer type (and possibly its modified status). The
warning/querying behavior should not depend on the particular command that calls
for the killing. And it should depend even less on the particular key binding of
that command.

That is my main point, I guess. I get the feeling that the discussion has been
approaching this problem backwards. We should back up from the supposedly
problematic key binding `C-x C-v' to the command `find-alternate-file' and
finally to the action `kill-buffer'. It's not very important _how_ you ask to
kill a buffer. What's important is that you do ask that, and what kind of buffer
you are trying to kill.

Does `C-x k' warn you the way you would like, when you use it in a *shell*
buffer? If not, then that is the problem, not something else. If `C-x k' does
warn you adequately, but `C-x C-v' does not, then that is the problem -
`find-alternate-file' should act as if `kill-buffer' were called interactively.

`find-alternate-file' does run `kill-buffer-query-functions' (but not when it
calls `kill-buffer', FWIW). I'm a bit surprised that doesn't take care of the
data-loss problem for *shell*. That var is not used in `shell.el'. I would think
that the concern for megabytes of data loss would be addressed here, where the
data is that could be lost.

And as you mentioned, `find-alternate-file' tests `(and (buffer-modified-p)
(buffer-file-name))'. I agree with you that the problem you are seeing is coming
from `(buffer-file-name)' being nil, and that removing that might be an
improvement.

[Bob Rogers]

   From: "Drew Adams" <drew.adams@...>
   Date: Fri, 3 Jul 2009 15:23:51 -0700

   . . .

   Does `C-x k' warn you the way you would like, when you use it in a *shell*
   buffer?  If not, then that is the problem, not something else.

It does indeed kill the *shell* buffer without prompting, which seems
odd, given that it prompts for modified files.  I notice that this code
uses the C equivalent of "(and (buffer-modified-p) (buffer-file-name))",
though it queries only if interactive, so a case could be made for
dropping the the "(buffer-file-name)" for symmetry.  But I have never
had the problem of invoking "C-x k" by accident (that I recall), so I'm
not sure such a case ought to be made.

   . . .

   And as you mentioned, `find-alternate-file' tests `(and
   (buffer-modified-p) (buffer-file-name))'. I agree with you that the
   problem you are seeing is coming from `(buffer-file-name)' being nil,
   and that removing that might be an improvement.

As far as I am concerned, removing "(buffer-file-name)" would be
sufficient.

   But I am really curious to know why Richard changed this in rev 1.192
to the current (and (buffer-modified-p) (buffer-file-name)) behavior.
Richard, do you remember?  I know this is asking a lot . . .

                                        -- Bob

[Richard Stallman]

    It's best to separate the concerns when analyzing the problem you ran into:
    consider both (a) the command behavior and (b) the key bindings. Whatever the
    binding, is `find-alternate-file' dangerous? If so, then let's fix its behavior.

It is somewhat dangerous _because_ it has a key binding.
We could try to fix its behavior, but maybe eliminating the
binding is easier.

    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.

but

[Drew Adams]

>     It's best to separate the concerns when analyzing the
>     problem you ran into: consider both (a) the command
>     behavior and (b) the key bindings. Whatever the
>     binding, is `find-alternate-file' dangerous? If so, then
>     let's fix its behavior.
>
> It is somewhat dangerous _because_ it has a key binding.

No, it was claimed that the command's behavior itself is dangerous, which means
regardless of how it is called. The fact that it has a key binding that might
cause it to be called unintentionally could be a further risk. It's still best
to analyze both issues.

> We could try to fix its behavior, but maybe eliminating the
> binding is easier.

That will not take care of the danger from the command behavior itself, if there
is such.

AFAICT, the danger (both dangers, in fact), comes from `kill-buffer' not warning
and asking for confirmation in the case of a *shell* buffer (or other non-file
buffer). If that happened, then there would be no problem whatsoever, IIUC. It
warns about modified file buffers, but not modified buffers in general. The OP
has, in effect, pointed out that there can be important data in non-file
buffers.

It is not something special in `find-alternate-file' that is the problem in this
regard; it is the fact that it kills the buffer with no warning - and it is just
its call of `kill-buffer' that is the culprit there.

Removing or changing the `C-x C-v' key binding is, I think, mostly beside the
point. If `C-x k' has the same problem, then mistaking a `k' for a `v' presents
the same problem as mistaking a `C-v' for a `v' or for a `C-f'. We've heard that
the OP has the same problem mistakenly typing either `C-x C-v' or `C-x C-f'
instead of `C-x v'. How many other keys are similar enough to a buffer-killing
key sequence to present essentially the same problem?

If the real problem is the danger of losing data because `kill-buffer' doesn't
warn when killing a non-file buffer such as *shell*, then that's what should be
addressed. It doesn't make sense to ignore that problem and just start moving
keys around, to try to avoid inadvertently killing the buffer in one situation
or another.

>     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.
>
> Of course, getting rid of the current buffer is why one uses it.

So we agree about that. I thought you were suggesting that a history list
somehow provided the same utility as `C-x C-v'.

> 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 think you mean `C-x k', not `C-x C-k'; if not, you've lost me.)

FWIW, as far as I'm concerned, the history is pretty irrelevant here. I don't
use `C-x C-v' to necessarily (or even usually) change to a file name that is on
the history. I use it to visit any file whatsoever (or Dired).

(Yes, some of the time I use it because I typed the wrong character and hit RET,
but that's not my typical use of it (in spite of the command name). And even in
that case, there is nothing particular that the history offers in this regard -
nothing implies that the file name I really wanted to type has been accessed
previously.)

Yes, a user can always use `C-x k' and then `C-x C-f' or whatever. But `C-x k'
apparently doesn't warn either. The only safety advantage in doing that instead
of `C-x C-v' is if you assume that `C-x k' is less likely to be invoked
accidentally. Certainly, there is (at least somewhat) less likelihood of
confusion with `C-x v <whatever>'. But confusion with other keys?

The danger of losing "megabytes of data" in *shell* is not logically related to
the choice of using a version-control command. _Any_ accidental invocation of
_any_ command that kills the *shell* buffer (or another modified buffer) without
warning presents the same problem. Confusing `C-x k' with `C-x C-k <whatever>'
(the kmacro prefix) is every bit as problematic as confusing `C-x C-v' with `C-x
v <whatever>' (the version-control prefix), I would think.

I think the question comes down to whether `kill-buffer' should warn in such a
context (modified buffer) or not. If not, then the problem remains, regardless
of any key shuffling we might do. If so, then that's the problem to fix.

[Drew Adams]

>    Does `C-x k' warn you the way you would like, when you use
>    it in a *shell* buffer?  If not, then that is the problem,
>    not something else.
>
> It does indeed kill the *shell* buffer without prompting,

Then the command-behavior problem has nothing to do with `find-alternate-file',
per se - any buffer-killing command will present the same problem. There remains
the other problem: that of key confusion raising the risk of accidentally using
some buffer-killing command.

> which seems odd, given that it prompts for modified files.
> I notice that this code uses the C equivalent of "(and
> (buffer-modified-p) (buffer-file-name))",

Donc, meme combat.

> though it queries only if interactive,

Yes, as I stated earlier, testing `interactive-p' should probably be part of the
mix. Non-interactive use of a command that kills a buffer should not necessarily
(or usually) query. It is the interactive use that we want to protect against.

> so a case could be made for dropping the the "(buffer-file-name)"
> for symmetry.

(Not just for symmetry.)

At least you and I agree about dropping `buffer-file-name' - dunno about others.

I maintain, however, that the proper test is `(or buffer-read-only
(buffer-modified-p))'. As I mentioned, there are some "modified" buffers that
one doesn't necessarily need to be warned about losing - things like *Buffer
List* and Dired.

The problem here is the concept of buffer "modification". If the aim is to
prevent data loss, then that aim is typically not advanced by not allowing a
modified read-only buffer to be dropped without query.

> But I have never had the problem of invoking "C-x k" by accident
> (that I recall), so I'm not sure such a case ought to be made.

Well, sure, you got stung because you use the version-control prefix, `C-x v', a
lot. If you used the kmacro prefix, `C-x C-k', a lot, then `C-x k' would sting
you. Any way of accidentally invoking any buffer-killing command presents the
same problem.

>    And as you mentioned, `find-alternate-file' tests `(and
>    (buffer-modified-p) (buffer-file-name))'. I agree with you that the
>    problem you are seeing is coming from `(buffer-file-name)'
>    being nil, and that removing that might be an improvement.
>
> As far as I am concerned, removing "(buffer-file-name)" would be
> sufficient.

We agree, modulo my wanting to be able to drop modified read-only buffers
without warning. Another way to look at that is that those buffers typically do
not have undo, which is another indication that we don't expect their contents
to be something we want to worry about saving. The proper test is, I think, `(or
buffer-read-only (buffer-modified-p))'.