From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Date: Wed, 26 Sep 2012 15:26:09 -0700 Message-ID: References: <87bogubqjy.fsf@gnu.org><873925ebpd.fsf@gnu.org> <87ipb031aj.fsf@kwarm.red-bean.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348698428 7583 80.91.229.3 (26 Sep 2012 22:27:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 22:27:08 +0000 (UTC) Cc: 'Chong Yidong' , 12507@debbugs.gnu.org To: "'Karl Fogel'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 27 00:27:13 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TH04W-0008E0-58 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2012 00:27:12 +0200 Original-Received: from localhost ([::1]:60682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TH04R-0001su-2b for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 18:27:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TH04N-0001sc-2Q for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 18:27:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TH04L-0001me-Ty for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 18:27:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TH04L-0001ma-Qb for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 18:27:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TH04L-000434-Ps for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 18:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 22:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12507 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12507-submit@debbugs.gnu.org id=B12507.134869837815512 (code B ref 12507); Wed, 26 Sep 2012 22:27:01 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 26 Sep 2012 22:26:18 +0000 Original-Received: from localhost ([127.0.0.1]:57607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TH03d-000428-LL for submit@debbugs.gnu.org; Wed, 26 Sep 2012 18:26:18 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:48896) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TH03a-000420-Qq for 12507@debbugs.gnu.org; Wed, 26 Sep 2012 18:26:16 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8QMQCGL009780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Sep 2012 22:26:13 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8QMQBAW019498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 22:26:11 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8QMQAi6009785; Wed, 26 Sep 2012 17:26:10 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Sep 2012 15:26:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ipb031aj.fsf@kwarm.red-bean.com> Thread-Index: Ac2cMGYpBiuVw5cCQXO1X+2HOcKqCAAAJxHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64937 Archived-At: > 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 > * 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