From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: save-excursion and save-current-buffer - edits to the manual Date: Sun, 13 Mar 2011 21:22:34 +0000 Message-ID: References: <19836.61380.828000.270873@gargle.gargle.HOWL> <1D85C3D14179400982EEB993C6CFFD99@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1300051392 32614 80.91.229.12 (13 Mar 2011 21:23:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2011 21:23:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 13 22:23:08 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pyskj-000612-9I for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2011 22:23:05 +0100 Original-Received: from localhost ([127.0.0.1]:54194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pyski-0003Wq-HS for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2011 17:23:04 -0400 Original-Received: from [140.186.70.92] (port=37448 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pyskd-0003Wl-Qf for emacs-devel@gnu.org; Sun, 13 Mar 2011 17:23:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pyskc-0001yP-HO for emacs-devel@gnu.org; Sun, 13 Mar 2011 17:22:59 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:59420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pyskc-0001yI-7M for emacs-devel@gnu.org; Sun, 13 Mar 2011 17:22:58 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PyskY-0005ye-TN for emacs-devel@gnu.org; Sun, 13 Mar 2011 22:22:54 +0100 Original-Received: from cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com ([92.232.137.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Mar 2011 22:22:54 +0100 Original-Received: from u.s.reddy by cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Mar 2011 22:22:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 104 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <1D85C3D14179400982EEB993C6CFFD99@us.oracle.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137197 Archived-At: On 3/13/2011 6:27 PM, Drew Adams wrote: >> The debate on save-excursion getting "defeated" flared up again on >> gnu.emacs.help. Somebody noticed that the Lisp manual hasn't been >> updated properly to take account of the new compiler warning. > > No, someone simply pointed out that the Lisp manual does not say what you were > trying to make it say. What it says is correct. It just hasn't yet been purged > of `save-excursion' the way you would like. And that's a good thing. I wasn't trying to settle the dispute in the manual, which is not the place for it anyway. The point is merely to make it faithful to the compiler and put enough helpful text for people that would be mystified by the new compiler warning. The Current Buffer section has not been updated after the compiler warning was introduced. So, it does need revision. In particular, it contradicts the compiler warning by saying explicitly that one can use save-excursion whereas the compiler says no. >> The attached patch/bundle is an attempt to explain the situation as >> well as to provide guidance on how to use these forms correctly. >> Please let me have any comments. > > My comment is to please leave it as it was. We can't, because it contradicts the compiler. > You have replaced mention of using `save-excursion' or `save-current-buffer' > when one uses `set-buffer' with just mention of using `save-current-buffer' with > it. Both can be useful here. No, the compiler complains about save-excursion being used for this purpose. > You've added this: > > "However, it is not a recommended use of `save-excursion' for reverting buffer > changes." > > The word "it" references nothing here - no meaning. If you really want "it" to refer to something, think of "it" as the compiler. > And `save-excursion' is not about reverting buffer changes - never has been. > And no one would ever think that it is. And the warning you then try to explain > also has nothing to do with reverting buffer changes. But this section is about buffer changes. And, in any case, the sentence before the one you quoted says: "save-excursion restores the current buffer and, in addition, restores the point and mark in that buffer as well." > And your explanation of the warning, like the warning itself, does not help. Since you think the warning doesn't help, I am not surprised that you don't find the explanation helpful. But, perhaps, you can be a bit more objective here? In what way does it not help? > And in your "recommended practice" section, you completely miss that > `save-excursion' is not only about restoring point (and mark). It is > specifically designed to restore `current-buffer' as well. > > And there should be no "there should be"s in technical doc: > > "there should be no calls to `set-buffer' in the intervening code > inside the `save-excursion' form before the changes to point or mark," > > Nonsense. Let's help users understand, not just give them a catechism to follow > blindly. > > "because `save-excursion' only restores the point and mark of > the current buffer, not for the other buffers that may be the target > of `set-buffer'" > > Doesn't follow at all. It does follow. Here is the logic, spelled out: 1. save-excursion should be placed as close as possible to the point/mark-movements. 2. save-excursion only restores the current buffer's point/mark. So, if there is a set-buffer between the save-excursion and the point/mark-movements, then it is not as close as possible to the point/mark-movements. (In fact, in the normal cases where the set-buffer's are not no-op's , there would have to be at least *two* set-buffer's between the save-excursion and the point/mark-movements that it is reverting.) > This is getting sillier and sillier. All because of a warning that no one can > decipher and the explanations for which go round and round...nowhere. Sorry, I have been able to decipher it just fine. On the other hand, I haven't been able to decipher what your objection is about. So, we could perhaps make some progress if you can help me understand your objection. If it is just a political position on what compilers should or should not do, I couldn't be interested because I didn't write the compiler. But if there is a technical point, what is it? Cheers, Uday