bug#12507: Have I mentioned how much I hate Debbugs?

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

> >We could do what I suggested in my message of 9/29:
> >
> >d> 3. Provide for optional backups, but if the user chooses not
> >d>    to back up, then do not visit the file.
> >d>
> >d> With #3, the user would pay the price that Stefan mentions for
> >d> visiting the file only when s?he chooses backup.
> >
> >I based that on my understanding (still asking the question 
> >though, since I'm not sure) that you cannot back up the file
> >unless you visit it.
>
> One thing I'm confused by:
> 
> Why does backing up a file have anything to do with visiting it?

Dunno.  That's why I wrote "still asking the question though".  And I've asked
Stefan several times now (a) whether it is the case that you cannot back up
without visiting and (b) if so, why.  No response, so far.

> Backing up just means making a copy.

Not exactly.  There is also a certain amount of checking and possibly
interaction with the user depending on various states.

> There is no reason why visiting the file in a buffer is necessary
> for that (surely `copy-file' does not visit the file, for example).

But the code for "backing up" (i.e., doing all that is necessary for that) seems
to be in `save-buffer'.  I don't see see any of that logic (checking this and
that) done elsewhere.

This kind of comes back to Thierry's suggestion that we might want to come up
with a version of `write-region', which does not visit the file it writes to,
that also backs up that file first.  Or to do something similar.

IOW, I don't see how to do it currently, other than visiting the file.

> Yet in this discussion, the assumption is that to get backups, we have
> to also visit the file.

I'm the one who said that.  But I am not sure.  That's the conclusion I came to
by looking around the code.  But I'm no expert at all.  And no one has corrected
my conclusion.

> >But those effects are anyway desirable, IF you want to back up the
> >file.  So it seems to me that what we want is to either (a) visit the
> >file and do `save-buffer' or `write-file or equivalent IF the option
> >value says to back up the file, or (b) do what we do not IF NOT.
> 
> Hmm, this feels like a workaround.  Instead, let's get to the 
> bottom of why backing up and visiting are linked at all.

Feel free to investigate.  My guess is that Stefan probably has the answer and
perhaps a simple solution.

> >In any case, it sounds like we have all agreed at least on 
> >the need of a way for a user to say whether or not s?he wants
> >backups.  `bookmark-version-control' does not do that - it controls 
> >only whether to use ordinary backups or numeric backups.  So I
> >think the first step is to add an option so that a user can
> >express that choice.
> 
> Yes, but...
> 
> Is it worth it to have even `bookmark-version-control' at all?
> The number of people who need backups on this file must be small, 

I think _most_ users should back it up.  I think the same for a user's
`custom-file' and for other user-data files that are typically not edited
directly.

The point is that users can make changes to such files, albeit indirectly, and
they can later wish that they had a previous version to revert to.

> since most users presumably do not edit it directly nor even know
> where it is.

See previous.  The directly vs indirectly difference is a red herring, IMO.  You
can easily change the file - you can even delete it.  It does not matter much
whether you do that by editing it directly, interactively, or by issuing a
general command that makes a change to it.

The real question - for a given user - is whether what is in the file is
important to that user and whether it would be difficult or take too long to
re-create it from scratch.

And also whether s?he might want to control/check/compare such changes
incrementally - January vs July versions, for instance, instead of all or
nothing - starting again from scratch.

It's about the cost of re-creation and the difficulty of knowing how to do that
- just what to re-create, and how to re-create the contexts that allow that
bookmark re-creation.

And yes, different users will have different answers.  People can use bookmarks
very differently.

> A more general solution might be `bookmark-before-save-hook'.  The few
> people who want backups can DTRT in the hook, and bookmark's code
> wouldn't need to worry about this at all.

I don't think it is (should be) only a few people.  Personally, I would suggest
turning numeric backups for this on by default.  Apparently I'm alone in that
opinion.

But the only argument given so far against this is the presumed "annoyance" of
users by "littering the filesystem".  That, to me, is presumptuous indeed.

Far better to, by default, protect user data, and let users opt out of that
default protection (backing up).

But we can agree to disagree.