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: Fri, 28 Sep 2012 13:00:45 -0700 Message-ID: References: <87bogubqjy.fsf@gnu.org><873925ebpd.fsf@gnu.org><87ipb031aj.fsf@kwarm.red-bean.com> <87sja4t48j.fsf@gmail.com><9D98A7802F07462887BCC67BE194243B@us.oracle.com> <87haqildr1.fsf@gmail.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 1348862521 32467 80.91.229.3 (28 Sep 2012 20:02:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 20:02:01 +0000 (UTC) Cc: 'Karl Fogel' , 12507@debbugs.gnu.org To: "'Thierry Volpiatto'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 28 22:02:06 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 1THgl8-0005jv-Bg for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2012 22:02:02 +0200 Original-Received: from localhost ([::1]:44268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THgl3-0007oc-0Q for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2012 16:01:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THgkz-0007oX-Ff for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 16:01:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THgky-0004JY-1i for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 16:01:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THgkx-0004JU-Tz for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 16:01:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1THgl8-0000im-EP for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 16:02: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: Fri, 28 Sep 2012 20:02: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.13488624712712 (code B ref 12507); Fri, 28 Sep 2012 20:02:02 +0000 Original-Received: (at 12507) by debbugs.gnu.org; 28 Sep 2012 20:01:11 +0000 Original-Received: from localhost ([127.0.0.1]:60931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THgkH-0000hg-Fv for submit@debbugs.gnu.org; Fri, 28 Sep 2012 16:01:10 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:51631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THgkE-0000hW-Kr for 12507@debbugs.gnu.org; Fri, 28 Sep 2012 16:01:08 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8SK0qXf008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Sep 2012 20:00:53 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8SK0oAv003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2012 20:00:51 GMT Original-Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8SK0nQa022432; Fri, 28 Sep 2012 15:00:49 -0500 Original-Received: from dradamslap1 (/10.159.184.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Sep 2012 13:00:49 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87haqildr1.fsf@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2dWE7mj/kaNm7DTt+r2JFNmud6GwANQjLg X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:64989 Archived-At: > > > What about improving write-region to use backup when needed? > > > Possibly writing a new write-region-something function that > > > handle backup, or a write-file-noselect function. > > > > +1 > > > > And please let us know how best to accomplish that (in the > > doc perhaps, but also in this thread). Anyone? > > It's not clear to me how to make a backup copy of a file > > without visiting that file in some buffer, however temporarily. Stefan? You were the one who pointed out why there was the change here to `write-region' from `write-file'. And you seemed to be suggesting that we should still avoid `write-file' for that reason. > > For example, I can imagine this as a way to append the > > region to a file and back it up: > > > > (write-region (point-min) (point-max) FILE 'append) > > (with-current-buffer (find-file-noselect FILE) (backup-buffer)) > > This is not efficient IMO, No, of course not. That's one reason I asked for a good way to do it. My question for the example here was for the APPEND case of `write-region', which has no equivalent wrt `write-file'. But I certainly agree that if we're going to visit the file anyway, then it is better to write to disk only once. For that I have no problem with (with-current-buffer (find-file-noselect FILE) ; erase if replacing, or leave in place if appending ; insert new (at end, if appending) (save-buffer)) > instead: 1) open FILE buffer 2) erase buffer > 3) write data to it 4) save buffer. Right. Sounds good to me. The question is open wrt visiting the file, however. > > But IIUC `find-file-noselect' visits the buffer (and so > > "asks the user for confirmation if the file was modified > > by some other process"). So that's apparently not the way > > to go. What is? > > What is the problem for this? I was quoting Stefan. He mentioned this problem as the reason for the 2005 change from the original `write-file' to the current `write-region'. His point was that we should avoid _visiting_ the file, for the reasons he gave. My question is how to create a backup if you do not visit the file. > What if you open another emacs session, bookmark something in this > session, (don't save and don't quit session) switch to the initial > session, bookmark something there and save bookmarks? > It is good if it ask you for confirmation at some point, no? > > > Leaving the question of visiting aside for the moment, what about > > `backup-buffer' here? Should it be `save-buffer' instead, > > so that the modes of FILE get updated properly? Should it be just > > `basic-save-buffer-1' instead of `save-buffer'? > > `save-buffer' do all the job (saving and backing up), so why > writing to buffer and then using `backup-buffer' > > > And should any such code take what Juri mentioned wrt vc > > into account? If so, how? > > `save-buffer' handle that. `save-buffer' means visiting the file first. As do all of the other, more partial, code combinations that might back up (`backup-buffer' etc.), AFAICT. > > It's not clear to me how best to handle this > > write-stuff-to-a-file-and-back-it-up-when-appropriate, but > > I (and perhaps others) would like to learn. I haven't found > > the answer by looking at the manuals or perusing the source > > code. Can you help? > > I think that doing like in the patch I sent is not too bad: > (with-current-buffer (find-file-noselect file) > write--data--here[...] (save-buffer)) > > No more is needed I think, but maybe I miss something? You are missing Stefan's point about not visiting the file. > Also, the use of `bookmark-version-control' is questionable, why > handling this file specially? If following that, we should have > a special variable for .emacs-custom.el, > desktop, history, etc... which is non--sense. No, it's not nonsense. Where I agree with you is that there can also be other places, besides bookmarking, where you might want what `version-control' does only in a blanket way to be done differently for specific files. That was the aim, I assume, behind creating `bookmark-version-control' in the first place. It might be better to have a more general or central way to specify this, rather than having additional user options for different files or libraries. (In Bookmark+, `bookmark-version-control' governs not only the bookmark file but also two other bookmarking files: Bmenu state and user-generated command definitions.) One approach might be to generalize (or particularize, depending on your point of view) `version-control', so that users can use it to also specify individual behaviors for specific files or file-name regexp matches. We could either modify `version-control' itself to get that effect or add a new option like this to do it: (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) The latter sounds better to me. Then, to have specific control for your bookmark file you would just add an entry like this: (bookmark-file . t). (BTW, bug #12533 concerns the incorrect behavior of Customize for such a defcustom.) > If this variable is removed, the global value of > version-control will be used and .emacs.bmk will be backed > up like any other file, But that might not be what you want. That's the point, presumably, of giving you specific control for your bookmark file. But I would be OK with removing variable `bookmark-version-control' if a more general variable such as `version-control-overrides' were added. > like it does (or should do because it is broken with > write-region) with its default value 'nospecial. > > Note that with the patch I sent, it seems a little bit faster to save, > but maybe I am wrong, need to verify. (we write one time the data and > save instead of writing two time and save) See above. Of course it is faster to write to disk only once. The question about visiting the file is still open, though.