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: Wed, 26 Sep 2012 16:46:28 -0500 Message-ID: <87ipb031aj.fsf@kwarm.red-bean.com> References: <87bogubqjy.fsf@gnu.org> <873925ebpd.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348696034 21581 80.91.229.3 (26 Sep 2012 21:47:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2012 21:47:14 +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 Wed Sep 26 23:47:19 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 1TGzRr-0004NT-MI for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 23:47:15 +0200 Original-Received: from localhost ([::1]:47941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGzRm-0003wz-HV for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2012 17:47:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGzRj-0003uY-Qq for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 17:47:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGzRe-00021z-1h for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 17:47:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGzRd-00021v-UW for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 17:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGzRd-00039u-M7 for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2012 17:47: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: Wed, 26 Sep 2012 21:47: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.134869599712108 (code B ref 12507); Wed, 26 Sep 2012 21:47:01 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 26 Sep 2012 21:46:37 +0000 Original-Received: from localhost ([127.0.0.1]:57556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGzRE-00039F-IV for submit@debbugs.gnu.org; Wed, 26 Sep 2012 17:46:36 -0400 Original-Received: from mail-ie0-f172.google.com ([209.85.223.172]:58589) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGzRC-000398-E8 for 12507@debbugs.gnu.org; Wed, 26 Sep 2012 17:46:36 -0400 Original-Received: by iec9 with SMTP id 9so2805382iec.3 for <12507@debbugs.gnu.org>; Wed, 26 Sep 2012 14:46:33 -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=WmCbTw6JjBUF0fCAHNm86ihH0btxsrr43hCUZtDK6Ww=; b=L86VvAkkJONIDcBgjxbPE2UYgjbwRzABKV/Xqd+G+mGk9XXyay8unrwF4xkE5qSEzv CHEudpVezJTwq0qIcaqHtfYzP4Zb25oLt6EpYw1Pisvlhw0qJOj9/pWyGsTuyQJT2LL3 AITzeHaQq7qXgH7XlTGoJZZvJ5rPCk4c959V+3ZkS7QGncWHxBvTV7bFPEGqFIu2DigN Rg5gzseiSvgATBDyqI2rngC1RZ3AfaFRSjJFF/wqS6eK4xg3Ycvod6jK+CBbnSDnSubS 3veWc/WUdnoGnFO6vTdHU/HjwoFYD7g6i5/7ZLeKA8a7BdqtfnocDRkosHH8BmM2mXAe G42w== Original-Received: by 10.50.220.129 with SMTP id pw1mr2222401igc.47.1348695993506; Wed, 26 Sep 2012 14:46:33 -0700 (PDT) Original-Received: from kwarm.red-bean.com (74-92-190-113-Illinois.hfc.comcastbusiness.net. [74.92.190.113]) by mx.google.com with ESMTPS id 8sm3640783ige.11.2012.09.26.14.46.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 14:46:30 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Tue, 25 Sep 2012 20:18:22 -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:64936 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... 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? 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" 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.