bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist

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

> I propose the following fix:
> 
>   * As Drew suggested, change `bookmark-write-file' to use 
>     `write-file' instead of `write-region'.
> 
>   * Also change the default value of `bookmark-version-control' to be
>     `nil' instead of `nospecial', so that backups of the bookmark data
>     file are no longer on by default (unless there are already backup
>     files present).

But how does that help a user turn backup on in the first place?  Not a
rhetorical question - I really don't know.  How should a user create the first
backup file?

What would the doc suggest to the user for that?  Copy the file to one with a
`~' suffix (error prone)?  Visit the bookmark file, type SPC then DEL, then `C-x
C-s' (error prone)?

What is an easy, sure way for a user who has never backed up a file (one that is
not typically visited interactively) to create a backup?

The question is not bookmark-specific.  I don't know a good answer.  It's
probably obvious, but I'm not seeing it.

> But... the only thing that makes me hesitate is the first 
> step, because back in 2005 we changed `bookmark-write-file' to use
> `write-region':
> 
>   2005-11-12  Karl Fogel  <kfogel@red-bean.com>
>         * bookmark.el (bookmark-write-file): Don't visit the 
>         destination file, just write the data to it using
>         write-region.  This is similar to revision 1.32 of
>         saveplace.el, but with an additional change to avoid
>         visiting the file in the first place.
> 
> The corresponding change in saveplace.el has just this comment:
> 
>   ;; Don't use write-file; we don't want this buffer to visit it.
> 
> Why didn't we want to visit the file?  Was there some reason why that
> was a bad thing?  Unfortunately, I don't remember, but I don't want to
> introduce a regression.
> 
> Drew or anyone, any idea what problem we were avoiding?

Sorry, I don't know.  I bisected the change logs from the start, to locate that
commit as the culprit change.  But I don't know more than what the log says.

Perhaps the reason was what Yidong expressed: a belief that a bookmark file is
only an "internal configuration file", rather than user data (presumably because
users do not typically edit it directly).  His contention is that backing up the
file would annoy users by littering their filesystems.

If that was the rationale for the 2005 change then it was misguided, IMO.

A bookmark file is not just an internal config file.  It contains user data that
can be valuable (to users).  Among other things, it can contain metadata (e.g.
annotations) about other files.  It has some things in common with Org mode for
keeping track of positions and other relations among documents.

Users can make mistakes that lead to losing individual bookmarks that they might
really want to keep, or even to losing all bookmarks.

In the other direction, it is very easy to load a second bookmark file into your
main bookmark file and save the result without necessarily meaning to.  To get
back what you had (by deleting the additions or replacing the replacements) is
laborious and error prone, unless you have a backup copy.

For such reasons, some users might want to have automatic backup for their
bookmarks.  I agree that backup should be optional and up to the user, of
course.
> The status quo does seem a bug.  There are two fixes: make 
> backups work again, or deprecate `bookmark-version-control'
> and don't claim that the bookmark data file can have automatic backups.
> 
> (In the meantime, Drew's suggestion in #12503 that `print-circle' be
> bound to `t' seems right to me -- I'm trying to get outstanding
> bookmark.el bugs fixed in time for the feature freeze on Oct. 
> 1 and that should be one of the fixes.  If so, then one of the reasons
> for being able to back up the bookmarks data file will go away anyway.)

Thank you for that, in advance.

There are however plenty of other ways a user can lose a bookmark file that took
a long time to construct.  To me, we should not only provide automatic backup
but turn it on by default.

(Would I apply the same arguments to some other "internal config files"?
Dunno/depends.  Maybe desktop files.  A lot depends on how important the given
"config" might be to a user and how long it takes to reconstruct it from
scratch.  In any case, I don't buy the blanket argument that dot files or
"internal config files" are necessarily things that a user does not want backed
up.)

---

I would in any case like to know an answer to my question above about creating
the first backup.

I also have a question about the idiom to use that would make a code change
analogous to the write-region --> write-file change discussed, but for
(write-region (point-min) (point-max 'APPEND), i.e., for appending the buffer
content to a file.

It's not clear to me what the best way would be to replace that code with code
that will not only append and write but also back up (if backing up is enabled).
I can code something up by appending the text to a buffer and then calling
`save-buffer' etc., but I wonder if there isn't some standard, simple way to get
this effect.

Thx - Drew