C-x C-v considered harmful

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/

Re: C-x C-v considered harmful

[Miles Bader]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> 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.

Re: C-x C-v considered harmful

[Bob Rogers]

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

   Bob Rogers <rogers-emacs@rgrjr.dyndns.org> 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? ")

Re: C-x C-v considered harmful

[Kevin Rodgers]

Miles Bader wrote:
> Bob Rogers <rogers-emacs@rgrjr.dyndns.org> 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

RE: C-x C-v considered harmful

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

RE: C-x C-v considered harmful

[Bob Rogers]

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

RE: C-x C-v considered harmful

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

RE: C-x C-v considered harmful

[Bob Rogers]

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

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.

RE: C-x C-v considered harmful

[Bob Rogers]

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

RE: C-x C-v considered harmful

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

RE: C-x C-v considered harmful

[Bob Rogers]

   From: "Drew Adams" <drew.adams@oracle.com>
   Date: Sun, 5 Jul 2009 00:13:36 -0700

   . . .

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

That would be even better, isn't it?  Absence of "undo" ought to be a
more reliable indication of which buffers are considered unlikely to
have state the user might regret trashing by accident.  What do you
think of querying only for modified buffers with undo enabled?

   I notice that this rule would query for Dired buffers, but only after
the user has started marking files.  And as soon as the user types "g",
the (buffer-modified-p) flag is cleared again.  This all strikes me as
correct behavior.

   In any case, you have convinced me that "C-x k" and "C-x C-v" should
have the same querying behavior.

					-- Bob

RE: C-x C-v considered harmful

[Drew Adams]

>    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 . . .
> 
> That would be even better, isn't it?  Absence of "undo" ought to be a
> more reliable indication of which buffers are considered unlikely to
> have state the user might regret trashing by accident.

Maybe, maybe not. My vague impression is that use of undo can be a bit irregular
(odd) sometimes; I'm not sure that presence of undo is the best thing to depend
on.

> What do you think of querying only for modified buffers with undo enabled?

I might be wrong, but I think the `buffer-read-only' test for modified buffers
is probably preferable to checking for undo. I think that a read-only modified
buffer often represents a different kind of "modification" - one that can
generally be ignored here. It's not clear to me how relevant an undo test might
be in general - probably sometimes quite relevant, but perhaps sometimes not so
relevant.

Perhaps someone else can offer insight here.

> I notice that this rule would query for Dired buffers, but 
> only after the user has started marking files.  And as soon as
> the user types "g", the (buffer-modified-p) flag is cleared again.
> This all strikes me as correct behavior.

These are all individual preferences, to some extent. One person's significant
modifications that s?he wants to be warned about losing is another person's
insignificant changes for which a warning would be annoying. Markings and undo
in Dired is an example of something I personally don't worry about saving -
warning about such changes would represent an annoyance, to me.

I'd sooner we concentrate on finding a solution for places where we can identify
a real problem - such as you did for `*shell*'. How many modified non-file
buffers are in the same class as `*shell*' of holding lots of significant data?
Dunno, but we don't want to end up casting a net that is too fine, and thereby
catch lots of buffers with modified data that one would never want to save.

I wonder if the best approach isn't the suggestion I made to just keep the
current test for a warning (i.e., modified file buffers), but add a user option
or two to specify buffers or classes of modified buffers (e.g. via regexps) for
which warnings would also be issued? The default value of said option(s) could
take care of any well-known cases, such as `*shell*'.

> In any case, you have convinced me that "C-x k" and "C-x 
> C-v" should have the same querying behavior.

I think you and I are in general agreement now. Whether that has any
significance wrt what ultimately gets done about this remains to be seen. 

Who knows what others might think, and whether even that matters for those who
actually decide. All we've heard so far from Stefan is that he wants to add
`confirm-nonexistent-file-or-buffer' to the mix (?!). We know that Richard has
expressed some interest, and initially a few others offered "fixes" to
`find-alternate-file'. But other than that, this seems to be a pas-de-deux.
(That in itself is somewhat of an indication, but by no means proof, that this
is not a big problem.)

Re: C-x C-v considered harmful

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> I wonder if the best approach isn't the suggestion I made to just keep
> the current test for a warning (i.e., modified file buffers), but add
> a user option or two to specify buffers or classes of modified buffers
> (e.g. via regexps) for which warnings would also be issued?

Or just use kill-buffer-query-functions.

Re: C-x C-v considered harmful

[Richard Stallman]

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

I don't remember, but I would guess it is becuase most non-file-visiting
buffers don't contain precious information.  I probably did not think
about the cases where they do.

RE: C-x C-v considered harmful

[Drew Adams]

>     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 don't remember, but I would guess it is becuase most 
> non-file-visiting buffers don't contain precious information.
> I probably did not think about the cases where they do.

To be clear about my own position: I said I think the right test for
`kill-buffer'  to use is `(or buffer-read-only (buffer-modified-p))', but that
is only if people decide that loss of data in non-file buffers is indeed a
problem that needs solving.

Personally, I don't have a problem with the current situation, but if we do
decide to make a change to prevent data loss in such buffers, then I think that
is the best such change.

Another, alternative possibility would be to test whether (besides a modified
file buffer) the buffer belongs to some specified set. The set of buffers to
warn about could be defined using a list of buffer names or regexps that match
buffer names.

I mention this because I think it does make sense that most modified non-file
buffers _not_ warn you when they are killed - perhaps even most that are not
read-only. If `kill-buffer' were to warn each time you kill such a buffer it
might prove annoying.

However, the `buffer-read-only' test would go a long way toward eliminating such
annoyance. Many non-file buffers that would be `buffer-modified-p' are in fact
read-only. That includes buffers such as `*grep*', `*Buffer List*', and Dired.
The "data" in such buffers is not normally something that we worry about losing
accidentally.

I guess the question is whether most other non-file buffers are more like
`*shell*', where a warning might be appropriate, or are more like `*grep*',
where a warning is probably inappropriate. If `*shell*' is rather the exception,
then perhaps it would be best to treat it as an exception, using, say, an option
`kill-buffer-warn-regexps', with a value of, say, `(,(regexp-quote "*shell*"))'.
IOW, do something similar to `same-window-regexps' and
`same-window-buffer-names'.

Re: C-x C-v considered harmful

[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 

RE: C-x C-v considered harmful

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

Re: C-x C-v considered harmful

[Richard Stallman]

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

Practically speaking, it is only dangerous because of the key binding.
If people had to run it with M-x, they would not type it by habit,
so it would not cause a problem.

RE: C-x C-v considered harmful

[Drew Adams]

>     > 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.
> 
> Practically speaking, it is only dangerous because of the key binding.
> If people had to run it with M-x, they would not type it by habit,
> so it would not cause a problem.

What you say is true of `kill-buffer' also. And `kill-buffer' presents exactly
the same problem reported: it does not warn you that you will lose data in a
`*shell*' buffer you kill.

Whether that problem is important is another question. But that is the problem
the OP reported. `find-alternate-file and `kill-buffer' are in exactly the same
boat. `find-alternate-file' is in this boat simply because it calls
`kill-buffer'. `kill-buffer' is what is problematic.

The solution is to make `kill-buffer' DTRT, either by improving its test (which
is currently just for a modified file buffer) or by letting users customize that
test.

Re: C-x C-v considered harmful

[Richard Stallman]

If people want kill-buffer to warn in some additional cases,
I won't argue against it.

Re: C-x C-v considered harmful

[Robert J. Chassell]

    Richard Stallman <rms@gnu.org> writes:

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

No.  The reason for using `find-alternate-file' is to visit an
alternative file while killing the current file.  Removing it would be
`C-x k RET C-x C-f <file name>'.  I have been using
`find-alternate-file' frequently recently (more than 50 times in the
past week; usually I don't use it so frequently, but I have been
having troubles with my wireless connection).

-- 
    Robert J. Chassell                          
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: C-x C-v considered harmful

[Juri Linkov]

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

I'd like to add one more use case of C-x C-v.  I use ffap that allows
C-x C-v to grab an absolute file name from the current buffer to
the minibuffer.  For example, one scenario is the following:

  M-x shell RET

  dpkg -L debian-package RET

This command outputs a list of absolute file names in the *shell* buffer.

  C-p C-p C-p ... C-x C-v RET

After moving point to the necessary absolute file name, C-x C-v
puts the file name to the minibuffer and RET just visits it.
I don't need to preserve the *shell* buffer after that.

However, maybe I would tolerate an yes-no confirmation in the *shell*
buffer since I more often use M-! for the same purposes.

Of course, this raises a question whether an information's worth in the
*shell* buffer is higher than in the *Shell Command Output* buffer
and shouldn't killing the *Shell Command Output* buffer ask a confirmation
as well?

Then what about the Async shell command that runs a command in the background?
Should C-x C-v ask a confirmation in the *Async Shell Command* buffer?
Currently it simply kills the child process without a question.

BTW, I am experiencing a higher risk of losing information with M-!
more than with C-x C-v.  M-! is difficult to type with one hand
because the `1' key is located directly above the Shift key,
so a combination with the Meta key often produces the wrong key M-1
(with Shift unpressed).  Typing a shell command in a Dired buffer
without paying attention to the screen results in a complete mess
(since most Dired keybndings are just one letter) that needs to be
analyzed afterwards to determine the damage (looking for files marked,
copied, moved, deleted, etc.)

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-x C-v considered harmful

[Drew Adams]

> Of course, this raises a question whether an information's 
> worth in the *shell* buffer is higher than in the *Shell
> Command Output* buffer and shouldn't killing the *Shell
> Command Output* buffer ask a confirmation as well?
> 
> Then what about the Async shell command that runs a command 
> in the background? Should C-x C-v ask a confirmation in the
> *Async Shell Command* buffer? Currently it simply kills the
> child process without a question.
> 
> BTW, I am experiencing a higher risk of losing information with M-!
> more than with C-x C-v.  M-! is difficult to type with one hand
> because the `1' key is located directly above the Shift key,
> so a combination with the Meta key often produces the wrong key M-1
> (with Shift unpressed).  Typing a shell command in a Dired buffer
> without paying attention to the screen results in a complete mess
> (since most Dired keybndings are just one letter) that needs to be
> analyzed afterwards to determine the damage (looking for files marked,
> copied, moved, deleted, etc.)

I thought we had moved forward from the question of `find-alternate-file' to the
question of `kill-buffer'. If you agree, then please, let's phrase the
discussion that way, going forward.

The question, for each of the particular contexts you cite, is whether
_`kill-buffer'_ should query/warn. How `kill-buffer' might be called is not the
point.

Re: C-x C-v considered harmful

[Juri Linkov]

> I thought we had moved forward from the question of `find-alternate-file' to the
> question of `kill-buffer'. If you agree, then please, let's phrase the
> discussion that way, going forward.
>
> The question, for each of the particular contexts you cite, is whether
> _`kill-buffer'_ should query/warn. How `kill-buffer' might be called
> is not the point.

I brought these examples to help deciding what a default list of buffers
should require a confirmation.  As Johan pointed out it is just a matter
of setting `kill-buffer-query-functions', e.g. in *shell* buffers.
But note that this can be annoying for users who like creating a lot
of shell buffers, so exiting from Emacs will ask a separate confirmation
for each of them.  (BTW, `C-x C-c' already asks a confirmation about
shell buffers.)

When doing this also please take care of not adding more confirmations
to existing ones.  For instance, currently `C-x C-v' on a modified
file buffer asks a confirmation twice (I think one confirmation
should be enough).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-x C-v considered harmful

[Juri Linkov]

> I brought these examples to help deciding what a default list of buffers
> should require a confirmation.  As Johan pointed out it is just a matter
> of setting `kill-buffer-query-functions', e.g. in *shell* buffers.
> But note that this can be annoying for users who like creating a lot
> of shell buffers, so exiting from Emacs will ask a separate confirmation
> for each of them.  (BTW, `C-x C-c' already asks a confirmation about
> shell buffers.)

This can be handled by the following code:

(add-hook 'kill-buffer-query-functions 'process-kill-buffer-query-function)

(defun process-kill-buffer-query-function ()
  "Ask before killing a buffer that has an active process."
  (let ((process (get-buffer-process (current-buffer))))
    (or (not process)
        (not (memq (process-status process) '(run stop open listen)))
        (not (process-query-on-exit-flag process))
        (yes-or-no-p "Buffer has an active process; kill it? "))))

It fixes both cases: killing a shell buffer as reported by OP,
and killing a *Async Shell Command* buffer as I reported.

The reason for doing this is the same as why exiting Emacs
with `C-x C-c' asks a question about killing active processes.
Active processes has the same worth to be asked a confirmation
regardless whether they are killed with `C-x k', `C-x C-v' or `C-x C-c'.

The variable `kill-buffer-query-functions' is nil by default,
so maybe it's better to implement this confirmation in Fkill_buffer
instead of the hook `kill-buffer-query-functions'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-x C-v considered harmful

[Drew Adams]

> The variable `kill-buffer-query-functions' is nil by default,
> so maybe it's better to implement this confirmation in Fkill_buffer
> instead of the hook `kill-buffer-query-functions'?

That's pretty much the original question (modulo a few trips we made around
Robinson's barn).

I don't think things should be hard-coded in `kill-buffer'. It's especially not
great to hard-code such stuff in C code.

This is the kind of thing for which it's good to both (a) provide reasonable
default behavior and (b) make it easy for users to change/override that
behavior. IOW, it's fine to do something smart here, but that should not be
hard-coded.

I suggested a separate option for identifying buffers for `kill-buffer'
confirmation query. That's one possibility. That is similar to
`kill-buffer-query-functions', but it is more specifically a list of buffer
names or name patterns. The confirmation behavior itself is already defined; all
we need additionally is to identify the buffers that require it. IOW,
`kill-buffer-query-functions' could be overkill here.

We could also make `kill-buffer-query-functions' a user option (i.e.,
customizable), and give it a default value that provides the behavior you
suggested.

Re: C-x C-v considered harmful

[Juri Linkov]

> This is the kind of thing for which it's good to both (a) provide reasonable
> default behavior and (b) make it easy for users to change/override that
> behavior. IOW, it's fine to do something smart here, but that should not be
> hard-coded.

This is already configurable via `set-process-query-on-exit-flag':

  Specify if query is needed for process when Emacs is exited.
  If the second argument flag is non-nil, Emacs will query the user before
  exiting if process is running.

We can just extend its semantics to "when Emacs is exited or
a buffer is killed".

This option is queried via `process-query-on-exit-flag'
as you can see in the code I sent.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-x C-v considered harmful

[Drew Adams]

> > This is the kind of thing for which it's good to both (a) 
> > provide reasonable default behavior and (b) make it easy
> > for users to change/override that behavior. IOW, it's fine
> > to do something smart here, but that should not be hard-coded.
> 
> This is already configurable via `set-process-query-on-exit-flag':
> 
>   Specify if query is needed for process when Emacs is exited.
>   If the second argument flag is non-nil, Emacs will query 
>   the user before exiting if process is running.
> 
> We can just extend its semantics to "when Emacs is exited or
> a buffer is killed".
> 
> This option is queried via `process-query-on-exit-flag'
> as you can see in the code I sent.

I have nothing to say about that, being ignorant.
Perhaps someone else has a comment.

However, you seem to be assuming that this is only about process buffers. It's
true that the OP's example was a *shell* buffer, which has an associated
process. But perhaps the inherent problem is more general?

I still wonder if being able to specify individual buffers (or classes of
buffers) for which confirmation is appropriate would not be a useful feature.
Dunno - as I said, I don't have a problem with the lack of a warning,
personally.

Re: C-x C-v considered harmful

[Juri Linkov]

> I have nothing to say about that, being ignorant.
> Perhaps someone else has a comment.
>
> However, you seem to be assuming that this is only about process buffers.
> It's true that the OP's example was a *shell* buffer, which has an
> associated process. But perhaps the inherent problem is more general?
>
> I still wonder if being able to specify individual buffers (or classes of
> buffers) for which confirmation is appropriate would not be a useful feature.
> Dunno - as I said, I don't have a problem with the lack of a warning,
> personally.

I have no opinion about a more general option.  The reason
why I proposed to ask a confirmation for process buffers is
because I personally have a problem with the *Async Shell Command*
buffer.  I sometimes kill it accidentally while it still runs
a process because usually there is no output and it is difficult
to see whether its process is finished or not.  There is only
a short unhighlighted string ":run" in the mode line that is
hard to notice.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: C-x C-v considered harmful

[Drew Adams]

> I have no opinion about a more general option.

Nor I.

> The reason why I proposed to ask a confirmation for process
> buffers is because I personally have a problem with the
> *Async Shell Command* buffer.  I sometimes kill it accidentally
> while it still runs a process because usually there is no
> output and it is difficult to see whether its process is
> finished or not.  There is only a short unhighlighted
> string ":run" in the mode line that is hard to notice.

Sounds like that is something else that could be improved, then: the feedback in
that context.

FWIW, I've been taking advantage of `kill-buffer''s lack of query for process
buffers as a _feature_, to avoid having to type `yes' (or is it `y'?) when I
kill Emacs to confirm that I want to kill any active processes. I've gotten in
the habit of using `C-x k' or `C-x C-v' when I'm through with a *shell* buffer,
for instance. (Yes, I realize that's as much typing as `yes'/`y', but it somehow
feels less annoying.) ;-)

RE: C-x C-v considered harmful

[Bob Rogers]

   From: "Drew Adams" <drew.adams@oracle.com>
   Date: Thu, 9 Jul 2009 16:21:49 -0700

   > I have no opinion about a more general option.

   Nor I.

Personally, I think I would be content if we added a query only for
active process buffers.

   . . .

   FWIW, I've been taking advantage of `kill-buffer''s lack of query for
   process buffers as a _feature_, to avoid having to type `yes' (or is
   it `y'?) when I kill Emacs to confirm that I want to kill any active
   processes. I've gotten in the habit of using `C-x k' or `C-x C-v'
   when I'm through with a *shell* buffer, for instance. (Yes, I realize
   that's as much typing as `yes'/`y', but it somehow feels less
   annoying.) ;-)

I just type "quit RET" to the shell.  And if I'm in an SSH session with
open tunneled connections, it won't exit immediately, so I'm reminded
that I have other state to take care of before doing C-x C-c.

					-- Bob

Re: C-x C-v considered harmful

[Juri Linkov]

> The variable `kill-buffer-query-functions' is nil by default,
> so maybe it's better to implement this confirmation in Fkill_buffer
> instead of the hook `kill-buffer-query-functions'?

Looking again at `find-alternate-file' convinces me that the right
solution is to use the `kill-buffer-query-functions' hook.

`find-alternate-file' explicitly runs this hook as:

  (run-hook-with-args-until-failure 'kill-buffer-query-functions)

and binds it to nil around killing the buffer to not ask again:

  (let ((kill-buffer-query-functions))
    (kill-buffer obuf))

So there is no good way to prevent asking a confirmation about a running
process in Fkill_buffer.

Asking a confirmation about a modified file buffer could be moved to the
`kill-buffer-query-functions' hook as well because this will avoid
duplicating this question in `find-alternate-file'.  But at least now
I propose to add a process confirmation to `kill-buffer-query-functions':

Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1055
diff -u -r1.1055 files.el
--- lisp/files.el	5 Jul 2009 22:15:37 -0000	1.1055
+++ lisp/files.el	13 Jul 2009 20:03:47 -0000
@@ -1441,6 +1441,16 @@
       (other-window 1)
       (find-alternate-file filename wildcards))))
 
+(defun process-kill-buffer-query-function ()
+  "Ask before killing a buffer that has a running process."
+  (let ((process (get-buffer-process (current-buffer))))
+    (or (not process)
+        (not (memq (process-status process) '(run stop open listen)))
+        (not (process-query-on-exit-flag process))
+        (yes-or-no-p "Buffer has a running process; kill it? "))))
+
+(add-hook 'kill-buffer-query-functions 'process-kill-buffer-query-function)
+
 (defun find-alternate-file (filename &optional wildcards)
   "Find file FILENAME, select its buffer, kill previous buffer.
 If the current buffer now contains an empty file that you just visited

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-x C-v considered harmful

[Juri Linkov]

> Looking again at `find-alternate-file' convinces me that the right
> solution is to use the `kill-buffer-query-functions' hook.

I found a better place for this piece of code.  subr.el has a special
section "Process stuff".

Also the docstring of `set-process-query-on-exit-flag' should be
modified to mention its effect on buffer killing.

Index: lisp/subr.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/subr.el,v
retrieving revision 1.641
diff -c -r1.641 subr.el
*** lisp/subr.el	14 Jul 2009 07:45:59 -0000	1.641
--- lisp/subr.el	16 Jul 2009 21:55:24 -0000
***************
*** 1722,1727 ****
--- 1722,1737 ----
      (set-process-query-on-exit-flag process nil)
      old))
  
+ (defun process-kill-buffer-query-function ()
+   "Ask before killing a buffer that has a running process."
+   (let ((process (get-buffer-process (current-buffer))))
+     (or (not process)
+         (not (memq (process-status process) '(run stop open listen)))
+         (not (process-query-on-exit-flag process))
+         (yes-or-no-p "Buffer has a running process; kill it? "))))
+ 
+ (add-hook 'kill-buffer-query-functions 'process-kill-buffer-query-function)
+ 
  ;; process plist management
  
  (defun process-get (process propname)

Index: src/process.c
===================================================================
RCS file: /sources/emacs/emacs/src/process.c,v
retrieving revision 1.589
diff -c -r1.589 process.c
*** src/process.c	28 Jun 2009 20:25:49 -0000	1.589
--- src/process.c	16 Jul 2009 21:55:57 -0000
***************
*** 1133,1139 ****
         2, 2, 0,
         doc: /* Specify if query is needed for PROCESS when Emacs is exited.
  If the second argument FLAG is non-nil, Emacs will query the user before
! exiting if PROCESS is running.  */)
       (process, flag)
       register Lisp_Object process, flag;
  {
--- 1133,1139 ----
         2, 2, 0,
         doc: /* Specify if query is needed for PROCESS when Emacs is exited.
  If the second argument FLAG is non-nil, Emacs will query the user before
! exiting or killing a buffer if PROCESS is running.  */)
       (process, flag)
       register Lisp_Object process, flag;
  {

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: C-x C-v considered harmful

[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

Re: C-x C-v considered harmful

[Miles Bader]

M Jared Finder <jared@hpalace.com> 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)

Re: C-x C-v considered harmful

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

Re: C-x C-v considered harmful

[Andreas Schwab]

Richard Stallman <rms@gnu.org> 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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C-x C-v considered harmful

[Miles Bader]

Richard Stallman <rms@gnu.org> 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

Re: C-x C-v considered harmful

[Markus Triska]

Kevin Rodgers <kevin.d.rodgers@gmail.com> 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.

Re: C-x C-v considered harmful

[Stefan Monnier]

I've just made C-x C-v obey confirm-nonexistent-file-or-buffer (as they
should have from the beginning) which should fix the OP's problem.


        Stefan

Re: C-x C-v considered harmful

[Bob Rogers]

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Mon, 06 Jul 2009 00:15:42 +0200

   I've just made C-x C-v obey confirm-nonexistent-file-or-buffer (as they
   should have from the beginning) which should fix the OP's problem.

	   Stefan

I'm sorry, but you seem to have misunderstood:  My problem with C-x C-v
is its behavior in killing buffers, not in how it finds files.  (That is
why I did not respond to your earlier post; as one who has never
*deliberately* invoked C-x C-v, I have no opinion.)

					-- Bob

Re: C-x C-v considered harmful

[Stefan Monnier]

>    I've just made C-x C-v obey confirm-nonexistent-file-or-buffer (as they
>    should have from the beginning) which should fix the OP's problem.

> I'm sorry, but you seem to have misunderstood:  My problem with C-x C-v
> is its behavior in killing buffers, not in how it finds files.  (That is
> why I did not respond to your earlier post; as one who has never
> *deliberately* invoked C-x C-v, I have no opinion.)

But it does fix the OP's particular case because the RET would have
asked to "[Confirm]" since here was no "d" file (or directory).


        Stefan

Re: C-x C-v considered harmful

[Bob Rogers]

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Sat, 11 Jul 2009 06:06:40 -0400

   >    I've just made C-x C-v obey confirm-nonexistent-file-or-buffer (as they
   >    should have from the beginning) which should fix the OP's problem.

   > I'm sorry, but you seem to have misunderstood:  My problem with C-x C-v
   > is its behavior in killing buffers, not in how it finds files.  (That is
   > why I did not respond to your earlier post; as one who has never
   > *deliberately* invoked C-x C-v, I have no opinion.)

   But it does fix the OP's particular case because the RET would have
   asked to "[Confirm]" since here was no "d" file (or directory).

	   Stefan

This did not occur to me.  But I notice that typing "C-x C-v d RET"
fails to require a "[Confirm]" if the value of
confirm-nonexistent-file-or-buffer is after-completion.  Since this is
the default, that is no help for those who have not yet been bitten by
this problem.  (It would in fact have helped me, as the OP, because I do
set confirm-nonexistent-file-or-buffer to t, but I have been flogging
this thread in the hope of making Emacs friendlier by default.)

   It is also unlikely to help if you had meant to type "C-x C-f"
instead of "C-x C-v"; both commands behave the same, regardless of the
confirm-nonexistent-file-or-buffer setting, up until the point the
previous buffer is killed.

   And it doesn't help at all with the fact that even "C-x k" is skimpy
in the warning department.  Are you rejecting Drew's argument that it is
really kill-buffer that needs attention (at least when invoked
interactively)?

					-- Bob

Re: C-x C-v considered harmful

[Stefan Monnier]

> This did not occur to me.  But I notice that typing "C-x C-v d RET"
> fails to require a "[Confirm]" if the value of
> confirm-nonexistent-file-or-buffer is after-completion.  Since this is

Oops, indeed, I forgot about this "detail".  Thanks for reminding me.

>    And it doesn't help at all with the fact that even "C-x k" is skimpy
> in the warning department.  Are you rejecting Drew's argument that it is
> really kill-buffer that needs attention (at least when invoked
> interactively)?

I do not oppose the change to kill-buffer, no.
I'm just happy that this thread pointed out the lack of support for
confirm-nonexistent-file-or-buffer in C-x C-v (and did so before the
release).


        Stefan

Re: C-x C-v considered harmful

[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