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: Have I mentioned how much I hate Debbugs? Date: Mon, 1 Oct 2012 15:00:54 -0700 Message-ID: <058D07630DCF42C18CA45AB3E07C0BF5@us.oracle.com> References: <87d312hltc.fsf@floss.red-bean.com> <87k3v9dgyc.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 1349128913 25462 80.91.229.3 (1 Oct 2012 22:01:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 22:01:53 +0000 (UTC) Cc: 12507@debbugs.gnu.org, 'Thierry Volpiatto' To: "'Karl Fogel'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 02 00:01:55 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 1TIo3c-0004CW-Bg for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Oct 2012 00:01:44 +0200 Original-Received: from localhost ([::1]:46116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIo3W-0007Et-Nv for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Oct 2012 18:01:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIo3T-0007Dv-9T for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 18:01:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIo3R-0006KH-W1 for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 18:01:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIo3R-0006KD-S0 for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 18:01:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TIo3t-0005su-SF for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 18:02: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: Mon, 01 Oct 2012 22:02: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.134912890522599 (code B ref 12507); Mon, 01 Oct 2012 22:02:01 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 1 Oct 2012 22:01:45 +0000 Original-Received: from localhost ([127.0.0.1]:36828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIo3c-0005sR-SJ for submit@debbugs.gnu.org; Mon, 01 Oct 2012 18:01:45 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:22765) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIo3Z-0005sI-Pc for 12507@debbugs.gnu.org; Mon, 01 Oct 2012 18:01:43 -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 q91M1BKr023910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 22:01:12 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 q91M19YO004390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 22:01:10 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91M19lH013059; Mon, 1 Oct 2012 17:01:09 -0500 Original-Received: from dradamslap1 (/10.159.219.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 15:01:09 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87k3v9dgyc.fsf@kwarm.red-bean.com> Thread-Index: Ac2gGxKWDkSgICRGRHiE0DpR7sGlgQAAXu6w 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:65097 Archived-At: > >We could do what I suggested in my message of 9/29: > > > >d> 3. Provide for optional backups, but if the user chooses not > >d> to back up, then do not visit the file. > >d> > >d> With #3, the user would pay the price that Stefan mentions for > >d> visiting the file only when s?he chooses backup. > > > >I based that on my understanding (still asking the question > >though, since I'm not sure) that you cannot back up the file > >unless you visit it. > > One thing I'm confused by: > > Why does backing up a file have anything to do with visiting it? Dunno. That's why I wrote "still asking the question though". And I've asked Stefan several times now (a) whether it is the case that you cannot back up without visiting and (b) if so, why. No response, so far. > Backing up just means making a copy. Not exactly. There is also a certain amount of checking and possibly interaction with the user depending on various states. > There is no reason why visiting the file in a buffer is necessary > for that (surely `copy-file' does not visit the file, for example). But the code for "backing up" (i.e., doing all that is necessary for that) seems to be in `save-buffer'. I don't see see any of that logic (checking this and that) done elsewhere. This kind of comes back to Thierry's suggestion that we might want to come up with a version of `write-region', which does not visit the file it writes to, that also backs up that file first. Or to do something similar. IOW, I don't see how to do it currently, other than visiting the file. > Yet in this discussion, the assumption is that to get backups, we have > to also visit the file. I'm the one who said that. But I am not sure. That's the conclusion I came to by looking around the code. But I'm no expert at all. And no one has corrected my conclusion. > >But those effects are anyway desirable, IF you want to back up the > >file. So it seems to me that what we want is to either (a) visit the > >file and do `save-buffer' or `write-file or equivalent IF the option > >value says to back up the file, or (b) do what we do not IF NOT. > > Hmm, this feels like a workaround. Instead, let's get to the > bottom of why backing up and visiting are linked at all. Feel free to investigate. My guess is that Stefan probably has the answer and perhaps a simple solution. > >In any case, it sounds like we have all agreed at least on > >the need of a way for a user to say whether or not s?he wants > >backups. `bookmark-version-control' does not do that - it controls > >only whether to use ordinary backups or numeric backups. So I > >think the first step is to add an option so that a user can > >express that choice. > > Yes, but... > > Is it worth it to have even `bookmark-version-control' at all? > The number of people who need backups on this file must be small, I think _most_ users should back it up. I think the same for a user's `custom-file' and for other user-data files that are typically not edited directly. The point is that users can make changes to such files, albeit indirectly, and they can later wish that they had a previous version to revert to. > since most users presumably do not edit it directly nor even know > where it is. See previous. The directly vs indirectly difference is a red herring, IMO. You can easily change the file - you can even delete it. It does not matter much whether you do that by editing it directly, interactively, or by issuing a general command that makes a change to it. The real question - for a given user - is whether what is in the file is important to that user and whether it would be difficult or take too long to re-create it from scratch. And also whether s?he might want to control/check/compare such changes incrementally - January vs July versions, for instance, instead of all or nothing - starting again from scratch. It's about the cost of re-creation and the difficulty of knowing how to do that - just what to re-create, and how to re-create the contexts that allow that bookmark re-creation. And yes, different users will have different answers. People can use bookmarks very differently. > A more general solution might be `bookmark-before-save-hook'. The few > people who want backups can DTRT in the hook, and bookmark's code > wouldn't need to worry about this at all. I don't think it is (should be) only a few people. Personally, I would suggest turning numeric backups for this on by default. Apparently I'm alone in that opinion. But the only argument given so far against this is the presumed "annoyance" of users by "littering the filesystem". That, to me, is presumptuous indeed. Far better to, by default, protect user data, and let users opt out of that default protection (backing up). But we can agree to disagree.