RE: C-x C-v considered harmful

["Drew Adams" <drew.adams@oracle.com>]

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