RE: C-x C-v considered harmful

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