From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: save-excursion and save-current-buffer - edits to the manual Date: Sun, 13 Mar 2011 11:27:13 -0700 Message-ID: <1D85C3D14179400982EEB993C6CFFD99@us.oracle.com> References: <19836.61380.828000.270873@gargle.gargle.HOWL> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1300040863 13476 80.91.229.12 (13 Mar 2011 18:27:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2011 18:27:43 +0000 (UTC) To: "'Uday S Reddy'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 13 19:27:39 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 1Pyq0w-0001AT-Qo for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2011 19:27:39 +0100 Original-Received: from localhost ([127.0.0.1]:33576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pyq0w-0005ea-7u for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2011 14:27:38 -0400 Original-Received: from [140.186.70.92] (port=55073 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pyq0o-0005do-O3 for emacs-devel@gnu.org; Sun, 13 Mar 2011 14:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pyq0n-0000Q3-C1 for emacs-devel@gnu.org; Sun, 13 Mar 2011 14:27:30 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:32729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pyq0n-0000Po-72 for emacs-devel@gnu.org; Sun, 13 Mar 2011 14:27:29 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2DIRGB5016966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Mar 2011 18:27:17 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2DIRFk2001005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Mar 2011 18:27:16 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2DIRFw1027892; Sun, 13 Mar 2011 13:27:15 -0500 Original-Received: from dradamslap1 (/10.159.54.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Mar 2011 11:27:15 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <19836.61380.828000.270873@gargle.gargle.HOWL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: Acvhm23jzFBe+R21SIydHNVnuHT4ywAAMEsQ X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D7D0C84.00BF,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 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:137195 Archived-At: > 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. > 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. 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. 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. 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. And your explanation of the warning, like the warning itself, does 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. That certainly is not a reason not to use `set-buffer' in the body of `save-excursion' before any point movements. No connection. In your "because A", A is true - so what? It does not follow that you should not move point in buffer X after calling (set-buffer X). 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. This is how we end up with "guidance" in the manual that is later pointed to as proof, The Word, and is hammered into user heads as a catechism. This is obviously a controversial area where judgments differ and programmer judgment is called for. Please do not try to carve one view of this in stone. Just give users the facts of what these functions do, and let them decide for themselves whether and how to use them. Users are not idiots, in general. Underlying your attempt to revise the manual here, your real contribution is in underlining that this message is incomprehensible and unhelpful on its own. The right solution is to get rid of the misguided message, IMO.