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

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
Why on earth would you relegate this to the wishlist?
This is about possible loss of user data.

I provided the fix, which takes 5 seconds to implement.
What's the problem?

Am I wrong that `write-region' does not provide for backups?
If not, then this is clearly a bug, and a pretty serious one, IMO.

bookmark.el even provides a user option, `bookmark-version-control', for
deciding whether and when to make numbered backups of the bookmark file.
AFAICT, that cannot possibly work if `write-region' does not create backups, as
is apparently the case.

FWIW, I made the same fix in Bookmark+.  I just think vanilla Emacs should
benefit its users as well.

Please read the bug report again and reconsider.  Thx.

> > severity 12507 wishlist
> > Bug #12507 [emacs] 24.2.50; `bookmark-write-file': use
> > `write-file', not `write-region', to get backups
> > Severity set to 'wishlist' from 'normal'




Reply | Threaded
Open this post in threaded view
|

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

Chong Yidong
"Drew Adams" <[hidden email]> writes:

> Am I wrong that `write-region' does not provide for backups?
> If not, then this is clearly a bug, and a pretty serious one, IMO.

It would be annoying litter the filesystem with backups for every
internal configuration file.  The abbrev file and desktop file are not
backed up either, and I think that's fine.

I wouldn't mind adding a global feature to optionally enable backups for
such files.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> > Am I wrong that `write-region' does not provide for backups?
> > If not, then this is clearly a bug, and a pretty serious one, IMO.
>
> It would be annoying litter the filesystem with backups for every
> internal configuration file.

Why not let _users_ decide what is annoying to them and their filesystems?  Some
users (and I know some) might well want a backup file for their bookmarks.  See
bug #12503 for a hint why.

But if you've already decided that a fix for this bug is not to be, because it
is a bad idea for a user to back up her bookmark file, then why send this bug to
the wishlist instead of marking it wontfix?  Or does wishlist for you really
mean the same thing as wontfix?

> The abbrev file and desktop file are not
> backed up either, and I think that's fine.

Is your `custom-file' an "internal configuration file"?  Do you back it up?

It is not just about what you think is fine for users - not when it comes to
user data.  It's about what individual users think about their data.  Let them
decide, please.

And as I said, we even have a user option for whether you want your
bookmark-file backups to be numbered: `bookmark-version-control'.  Imagine that!
Besides `version-control', which applies to all files, we even give you a
special option that applies only to your bookmark file.

What do you think is the point of that option, if your bookmark file is in fact
NEVER backed up at all?  Do you not see a bug here?

> I wouldn't mind adding a global feature to optionally enable
> backups for such files.

Fine.  Let users enable backups, please.  I have no problem with making that a
user option.

But in that case please document the fact that `bookmark-version-control' has no
effect when your new option is turned off (no backups).  Let's make it as clear
as possible how to (a) turn backing up on/off and (b) control the backup naming
when on.




Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
> the wishlist instead of marking it wontfix?  Or does wishlist for you really
> mean the same thing as wontfix?

wishlist means "patches welcome".


        Stefan



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> > the wishlist instead of marking it wontfix?  Or does
> > wishlist for you really mean the same thing as wontfix?
>
> wishlist means "patches welcome".

Oh, come on.  I provided the patch: use `write-file' instead of `write-region'.




Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
>> > the wishlist instead of marking it wontfix?  Or does
>> > wishlist for you really mean the same thing as wontfix?
>> wishlist means "patches welcome".
> Oh, come on.  I provided the patch: use `write-file' instead of
> `write-region'.

Oh come on, you know it's not good enough because we'd rather not have
backups by default.


        Stetfan



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> Oh come on, you know it's not good enough because we'd rather not have
> backups by default.

You don't have backups at all.  So maybe you'd better get rid of option
`bookmark-version-control', while waiting for your wishlist to come true
someday.

Someone obviously did prefer to have backups by default, and not only by
default, or you wouldn't have that neutered option hanging around as a vestige.




Reply | Threaded
Open this post in threaded view
|

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

Karl Fogel-2
In reply to this post by Drew Adams
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... 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  <[hidden email]>
        * 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?

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

-Karl

"Drew Adams" <[hidden email]> writes:

>It is not just about what you think is fine for users - not when it comes to
>user data.  It's about what individual users think about their data.  Let them
>decide, please.
>
>And as I said, we even have a user option for whether you want your
>bookmark-file backups to be numbered: `bookmark-version-control'.  Imagine that!
>Besides `version-control', which applies to all files, we even give you a
>special option that applies only to your bookmark file.
>
>[...]
>
>What do you think is the point of that option, if your bookmark file is in fact
>NEVER backed up at all?  Do you not see a bug here?
>
>> I wouldn't mind adding a global feature to optionally enable
>> backups for such files.
>
>Fine.  Let users enable backups, please.  I have no problem with making that a
>user option.
>
>But in that case please document the fact that `bookmark-version-control' has no
>effect when your new option is turned off (no backups).  Let's make it as clear
>as possible how to (a) turn backing up on/off and (b) control the backup naming
>when on.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> 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  <[hidden email]>
>         * 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




Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> >   * 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.

Sorry, I wasn't paying attention.  It's not about creating the first backup
file, but the first numbered backup file.  The question remains (how do users do
that?), but my examples were incorrect.




Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Karl Fogel-2
>   ;; Don't use write-file; we don't want this buffer to visit it.

After write-file, the buffer is marked as visiting that file, which
affects the behavior of C-x C-f and a lot more (e.g. asks the user
for confirmation if the file was modified by some other process, ...).


        Stefan



Reply | Threaded
Open this post in threaded view
|

bug#12507: `bookmark-write-file': use `write-file', not `write-region', to get backups

Juri Linkov
In reply to this post by Drew Adams
> Is your `custom-file' an "internal configuration file"?  Do you back it up?

`custom-file' has the opposite problem: it creates backups forcefully
even when backups should not be created in VC-controlled directories.

There is a bug in `custom-save-all', it binds `print-length'
and `print-level' to nil (but not `print-circle' to t), and
calls `save-buffer' that ignores the VC status and creates backups.

I have no problems with backups for configuration files
like e.g. .recentf~ or .emacs.desktop~ when a VCS is not used,
but while implementing backups for bookmarks please take into account
that it should not create backups in VC-controlled directories.

I guess normal `save-buffer' or `write-file' should take care about this
by creating backups only in non-VC directories, or creating numbered
backups if there are already existing numbered backups.



Reply | Threaded
Open this post in threaded view
|

bug#12507: `bookmark-write-file': use `write-file', not `write-region', to get backups

Drew Adams
> while implementing backups for bookmarks please take into account
> that it should not create backups in VC-controlled directories.
>
> I guess normal `save-buffer' or `write-file' should take care
> about this by creating backups only in non-VC directories, or
> creating numbered backups if there are already existing numbered
> backups.

What you say in the second sentence sounds like the right approach.
This problem doesn't sound like it is specific to bookmarks.
IOW, it should be the subject of another bug ("wishlist") report.




Reply | Threaded
Open this post in threaded view
|

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

Karl Fogel-2
In reply to this post by Drew Adams
"Drew Adams" <[hidden email]> writes:

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

Set `bookmark-version-control' to `t', of course.

Best,
-K

>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  <[hidden email]>
>>         * 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



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> >>   * 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?
>
> Set `bookmark-version-control' to `t', of course.

OK, I thought of that, but that seems like a strange thing for the doc to
suggest: customize it to `t', save your bookmark file, then re/un-customize it
back to the default, `nil'.

Is that really the best recommendation?  I have no special problem with it, but
somehow I was expecting something else.  

Whatever the recommended procedure is, I think the doc (for this and
`version-control') should suggest it to users.




Reply | Threaded
Open this post in threaded view
|

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

Karl Fogel-2
"Drew Adams" <[hidden email]> writes:
>> Set `bookmark-version-control' to `t', of course.
>
>OK, I thought of that, but that seems like a strange thing for the doc to
>suggest: customize it to `t', save your bookmark file, then re/un-customize it
>back to the default, `nil'.

Sorry?  I'm maybe not understanding your question.

If a user wants numbered backups of their bookmark data file, then they
would set (customize) `bookmark-version-control' to `t'.  If they don't,
then it's nil.  That is: they can leave it as the default (which would
be nil in my proposal) or if they really want to be certain, I suppose
they could explicitly customize it to nil.

>Is that really the best recommendation?  I have no special problem with
>it, but somehow I was expecting something else.

Can you describe what you were expecting?

Controlling numbered backups of the bookmark data file is the whole
reason the variable exists in the first place, so users should expect
that if they want to control that behavior, this variable is the place
to look.  (Of course it should be documented; my point is just that I
can't imagine what *other* mechanism would control this, since the only
reason the current mechanism exists is ... to control exactly this.)

-K



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> >> Set `bookmark-version-control' to `t', of course.
> >
> > OK, I thought of that, but that seems like a strange thing
> > for the doc to suggest: customize it to `t', save your bookmark
> > file, then re/un-customize it back to the default, `nil'.
>
> Sorry?  I'm maybe not understanding your question.

My bad.  Please ignore the question.

The values essentially come from `version-control', where what's being decided
is for all files.  Since this is only for the bookmark file there is not a big
need for offering both `nil' and `never' values.  I think that is what confused
me somehow.

The only real choices for the bookmark file are using numbered or unnumbered
backups, and whether to let `version-control' decide that: i.e., values `t',
`never', and `nospecial'.

`nil' (vs `t') has meaning here only if you somehow already had a numbered
backup for the bookmark file.  `nil' makes sense for `version-control', however,
because that option governs multiple files.

If the value here is `nospecial' and the `version-control' value is `nil', then
you get the same result as `never' for the bookmark file, unless you previously
customized `b-v-c' to `t'.  I think that's the case that I was finding
confusing.  I was wondering how, in that case, a user might have created a
numbered backup in the first place.

It's not important.  Sorry for the noise.




Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Chong Yidong
> >> Am I wrong that `write-region' does not provide for backups?
> >> If not, then this is clearly a bug, and a pretty serious one, IMO.
> >
> > It would be annoying litter the filesystem with backups for every
> > internal configuration file.  The abbrev file and desktop file are not
> > backed up either, and I think that's fine.
> >
> > I wouldn't mind adding a global feature to optionally enable backups for
> > such files.
>
> Indeed; data files are normally not backed up, and the bookmark file is
> one such file.  So I'm closing this bug report.
>
> If somebody wants a global "make write-region make backup files"
> (possibly on a per-mode basis?), then a new bug report should be opened.

No, `write-region' should not, itself, make a backup file.

It's not blanket either-everything-or-nothing.  Some
"data" files deserve backup; some don't.

A bookmark file definitely does deserve it.  It's
typically updated frequently (each time a bookmark
is visited).

Emacs goes out of its way to protect user data.  Why
now we would think that only "code" or non-"data"
files deserve backing up, I can't imagine.

Some "data" files are quite important.  A bookmark
file is one such.  `bookmark-write-file' should
use `write-file', not `write-region'.  I made that
change in Bookmark+ 8 years ago.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Drew Adams <[hidden email]> writes:

> No, `write-region' should not, itself, make a backup file.

No, but there should perhaps be a global mechanism for modes to decide
whether the data it writes should have backup files, and these modes
should then call a wrapper around `write-region' that does this stuff.

And it should be user-customisable, if it exists.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> > No, `write-region' should not, itself, make a backup file.
>
> No, but there should perhaps be a global mechanism for modes to decide
> whether the data it writes should have backup files, and these modes
> should then call a wrapper around `write-region' that does this stuff.
>
> And it should be user-customisable, if it exists.

Huh?  This is about a particular context (mode, if
you like).  In _this particular context_ the proper
behavior is to use `write-file'.  There's zero reason
to use `write-region' in this context.  And to fix
this context in this regard there's zero reason to
propose some far-reaching, general change to
`write-region'.

`write-region' is simply the wrong function to use
in this context.  Trying to generalize this for all
contexts is a different solution (in search of a
problem).

The subject of this bug report is:
"`bookmark-write-file': use `write-file', not
`write-region' , to get backups"

To be clear, if this isn't clear already: This
doesn't affect me or my code, personally, because
I fixed this long ago in Bookmark+.  I'm just
trying to help vanilla Emacs DTRT.

There's a real bug here, which I can attest to
because Bookmark+ users have lamented not having
backed up their bookmark files (before I fixed the
code to use `write-file').

There's no reason to expect or require users to
manually back up their bookmark files, especially
when it's trivial for Emacs itself to DTRT and
provide backup by default.  By _default_.



12