From: Karl Fogel <kfogel@red-bean.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Chong Yidong' <cyd@gnu.org>, 12507@debbugs.gnu.org
Subject: bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist
Date: Thu, 27 Sep 2012 10:48:22 -0500 [thread overview]
Message-ID: <87obkreabd.fsf@floss.red-bean.com> (raw)
In-Reply-To: <B732ED58C8E94B64ACAC620E8EDBCD2A@us.oracle.com> (Drew Adams's message of "Wed, 26 Sep 2012 15:26:09 -0700")
"Drew Adams" <drew.adams@oracle.com> 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 <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
next prev parent reply other threads:[~2012-09-27 15:48 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87bogubqjy.fsf@gnu.org>
[not found] ` <handler.s.C.13485522721217.transcript@debbugs.gnu.org>
2012-09-25 13:53 ` bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Drew Adams
2012-09-26 2:53 ` Chong Yidong
2012-09-26 3:18 ` Drew Adams
2012-09-26 4:04 ` Stefan Monnier
2012-09-26 14:19 ` Drew Adams
2012-09-26 19:46 ` Stefan Monnier
2012-09-26 20:31 ` Drew Adams
2012-09-26 21:46 ` Karl Fogel
2012-09-26 22:26 ` Drew Adams
2012-09-26 23:36 ` Drew Adams
2012-09-27 15:48 ` Karl Fogel [this message]
2012-09-27 16:00 ` Drew Adams
2012-09-27 17:57 ` Karl Fogel
2012-09-27 18:32 ` Drew Adams
2012-09-27 3:24 ` Stefan Monnier
2012-09-24 18:41 ` bug#12507: 24.2.50; `bookmark-write-file': use `write-file', not `write-region', to get backups Drew Adams
2012-09-27 5:38 ` bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Thierry Volpiatto
2012-09-27 18:37 ` Drew Adams
2012-09-27 21:16 ` Thierry Volpiatto
2012-09-28 9:04 ` Thierry Volpiatto
2012-09-28 20:00 ` Drew Adams
2012-09-29 7:42 ` Thierry Volpiatto
2012-09-29 14:36 ` Drew Adams
2012-09-29 15:12 ` Thierry Volpiatto
2012-09-29 15:51 ` Drew Adams
2012-09-29 16:20 ` Thierry Volpiatto
2012-09-29 16:50 ` Drew Adams
2012-09-29 16:57 ` Thierry Volpiatto
2012-10-01 3:38 ` bug#12507: Option `(bookmark-)version-control': Use :tag so doc string matches menu Karl Fogel
2012-10-01 4:06 ` bug#12507: Option `(bookmark-)version-control': Use :tag so docstring " Drew Adams
2012-10-01 4:13 ` bug#12507: Have I mentioned how much I hate Debbugs? Karl Fogel
2012-10-01 4:50 ` Drew Adams
2012-10-01 21:23 ` Karl Fogel
2012-10-01 22:00 ` Drew Adams
2012-10-02 5:31 ` Thierry Volpiatto
2020-11-29 1:07 ` bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Karl Fogel
2012-09-27 8:36 ` bug#12507: `bookmark-write-file': use `write-file', not `write-region', to get backups Juri Linkov
2012-09-27 15:02 ` Drew Adams
2020-09-18 15:02 ` bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Lars Ingebrigtsen
2020-09-18 16:23 ` Drew Adams
2020-09-19 14:18 ` Lars Ingebrigtsen
2020-09-19 17:29 ` Drew Adams
2020-09-23 6:41 ` Karl Fogel
2020-09-23 13:34 ` Lars Ingebrigtsen
2020-09-23 16:23 ` Eli Zaretskii
2020-09-24 13:58 ` Lars Ingebrigtsen
2020-09-29 5:27 ` Karl Fogel
2020-09-29 14:29 ` Lars Ingebrigtsen
2020-09-23 14:27 ` Eli Zaretskii
2020-09-23 18:13 ` Drew Adams
2020-09-23 18:14 ` Drew Adams
2020-09-29 5:25 ` Karl Fogel
2020-09-29 15:45 ` Drew Adams
2020-11-29 0:28 ` Karl Fogel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obkreabd.fsf@floss.red-bean.com \
--to=kfogel@red-bean.com \
--cc=12507@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).