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.

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

[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

[Bob Rogers]

   From: Stefan Monnier <monnier@...>
   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

[Bob Rogers]

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

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

[Robert J. Chassell]

    Richard Stallman <rms@...> 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@...                         bob@...
    http://www.rattlesnake.com                  http://www.teak.cc

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

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

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

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

[Richard Stallman]

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

[Johan Bockgård]

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

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

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

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

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

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

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

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