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: Sun, 30 Sep 2012 21:50:19 -0700 Message-ID: References: <87d312hltc.fsf@floss.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 1349067049 2291 80.91.229.3 (1 Oct 2012 04:50:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 04:50:49 +0000 (UTC) To: "'Karl Fogel'" , <12507@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 01 06:50: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 1TIXxv-0005sA-M9 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Oct 2012 06:50:47 +0200 Original-Received: from localhost ([::1]:39272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIXxq-00057j-8M for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Oct 2012 00:50:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIXxn-00057d-CA for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 00:50:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIXxm-0002Sq-3c for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 00:50:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIXxm-0002Si-0H for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 00:50:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TIXyA-0003OQ-3m for bug-gnu-emacs@gnu.org; Mon, 01 Oct 2012 00:51:02 -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 04:51:02 +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.134906706113035 (code B ref 12507); Mon, 01 Oct 2012 04:51:02 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 1 Oct 2012 04:51:01 +0000 Original-Received: from localhost ([127.0.0.1]:35450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXy8-0003OC-RZ for submit@debbugs.gnu.org; Mon, 01 Oct 2012 00:51:01 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:27828) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXy6-0003O3-PS for 12507@debbugs.gnu.org; Mon, 01 Oct 2012 00:50:59 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q914oWrZ004054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 04:50:33 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q914oWEh007286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 04:50:32 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q914oWL9022498; Sun, 30 Sep 2012 23:50:32 -0500 Original-Received: from dradamslap1 (/10.159.219.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Sep 2012 21:50:31 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87d312hltc.fsf@floss.red-bean.com> Thread-Index: Ac2fiyfDwvEK8aSGS2u+Sw/dhOKc5QAAm8JQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:65053 Archived-At: > So, immediately after I mis-closed this report, I realized > what happened and ever since then I've been trying to reopen it. > > First I emailed "12507-open@". Then I tried "12507-reopen@". Maybe > those emails are stuck in the pipe somewhere, or maybe those weren't > valid ways to issue the command to reopen. I don't think those are valid ways. > In any case, now I'm reduced to sending this mail and praying that > it goes through, since unlike every other bug tracker created > since 1852 debbugs does not have a way to manipulate bugs via the > web browser. ;-) I just sent a reopen message, which looks like it worked. I too know little about Debbugs. For this, all you need to do is to send a message to 'control@debbugs.gnu.org' with this in the message body (without quotes): "reopen 12507". > In any case: > This bug is too complex to solve by the Oct. 1st freeze, sorry. It's not complex, IMO, but it definitely won't be fixed by Oct 1! I think we need to wait for Stefan to weigh in on the question, for one thing. > Just reading & comprehending the conversation takes twenty minutes > now. My preference would be to remove the `bookmark-version-control' > variable entirely, since probably so few people use it and it's now a > bug source. I disagree with that, but I can keep a local version if you decide to do that. What I would prefer is a general solution, along the lines I suggested (in my mail of 9/28): extend the general `version-control' to let users specify backup for particular files. I proposed adding an option like this, as one way to do that: (defcustom version-control-overrides () "Control the use of version numbers for backing up specific files. Each entry is of the form (REGEXP-OR-VARIABLE . VALUE), where: REGEXP-OR-VARIABLE is a regexp matching file names or the name of a file name-valued variable. VALUE has the same meaning as the value of option `version-control, but affects only the files whose names match REGEXP." :type '(repeat (cons :tag "File & when" (choice (regexp :tag "File-name regexp") (variable :tag "File-name variable")) (choice (const :tag "Never" never) (const :tag "If existing" nil) (other :tag "Always" t)))) :group 'backup :group 'vc) Then, to handle the file that is the value of variable `bookmark-file' you would just add an entry like this: (bookmark-file . t). > However, maybe it's important enough to keep, in which case > we probably need to fix `write-region' to DTRT with backups, > or at least have some kind of `write-region-make-backups' > variable we can dynamically bind. > > I don't want to revert to using `write-file'. We switched *away* from > `write-file' for a reason. Going back will probably mean a regression > of some sort. 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. Stefan's objection, and the reason we moved away from `write-file', is that a user might not want to visit the file, since that has some additional effects (e.g. asking for confirmation if some other process modified the file). 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. 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.