From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.bugs Subject: bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist Date: Thu, 27 Sep 2012 10:48:22 -0500 Message-ID: <87obkreabd.fsf@floss.red-bean.com> References: <87bogubqjy.fsf@gnu.org> <873925ebpd.fsf@gnu.org> <87ipb031aj.fsf@kwarm.red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348760948 12228 80.91.229.3 (27 Sep 2012 15:49:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2012 15:49:08 +0000 (UTC) Cc: 'Chong Yidong' , 12507@debbugs.gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 27 17:49: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 1THGKu-0001wy-FR for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2012 17:49:12 +0200 Original-Received: from localhost ([::1]:60566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THGKp-0000bf-E8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2012 11:49:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THGKm-0000bX-1w for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 11:49:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THGKg-0005NK-0i for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 11:49:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THGKf-0005NG-SV for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 11:48:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1THGKj-0007Jg-HC for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 11:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Karl Fogel Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Sep 2012 15:49: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.134876094028115 (code B ref 12507); Thu, 27 Sep 2012 15:49:01 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 27 Sep 2012 15:49:00 +0000 Original-Received: from localhost ([127.0.0.1]:59078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THGKh-0007JP-9V for submit@debbugs.gnu.org; Thu, 27 Sep 2012 11:48:59 -0400 Original-Received: from mail-ie0-f172.google.com ([209.85.223.172]:44697) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THGKe-0007JH-AM for 12507@debbugs.gnu.org; Thu, 27 Sep 2012 11:48:57 -0400 Original-Received: by iec9 with SMTP id 9so4937052iec.3 for <12507@debbugs.gnu.org>; Thu, 27 Sep 2012 08:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=WR5TorjUMSwIjyPKvBJjIuR01Rx/Rj26AkqLxs3arp4=; b=zCulGG0YyqodrkJzf4kbQRZUa/z/cIAnWavtSoIdgj/mQIcUJ8oAppoKH6PTpvuP6x 4Zi7/hPAcGVh2Wzme4DMhc5aM0WyEoFk4wF5QFqquLnoxD90wDShm4M9MIc5NlGOrCSi iNsNEvOKwar3vHPoLlJ5EnyxrhZyyKDvE24fFgsnTkQ9T846iCrnRg4lRvfyJjQuiJ1P WCyvHTCp+wXh02dNAW2FlND/ulJfrqZ6gc2nViG9Mma6m+BsA90uTvnkw1NkbWahIBLH wNP8djx0DwJyTqMrsFMeixVI7BZ9SlP3sh//4L/uK/cbLT2FGihPCRwh2b0t+Q0ruq0w pT3Q== Original-Received: by 10.50.236.72 with SMTP id us8mr3893862igc.70.1348760931123; Thu, 27 Sep 2012 08:48:51 -0700 (PDT) Original-Received: from floss.red-bean.com (173-108-184-40.pools.spcsdns.net. [173.108.184.40]) by mx.google.com with ESMTPS id a10sm5542228igd.1.2012.09.27.08.48.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:48:49 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Wed, 26 Sep 2012 15:26:09 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) 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:64955 Archived-At: "Drew Adams" 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 >> * 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