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' defeated by `set-buffer' Date: Tue, 5 Jan 2010 16:02:39 -0800 Message-ID: <558DC61A9B3E4FF89CC53FF9DF7F7709@us.oracle.com> References: <87aaxdqwqv.fsf@regnitz.physics.niu.edu><876380nvnt.fsf@lola.goethe.zz><87hbrijbyg.fsf@lola.goethe.zz><87skb0iw04.fsf@lola.goethe.zz> <1DA372296B5F41A1A3317F557D27355D@us.oracle.com> <87ocl8gvcn.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1262742911 30529 80.91.229.12 (6 Jan 2010 01:55:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2010 01:55:11 +0000 (UTC) To: "'David Kastrup'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 06 02:55:04 2010 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.50) id 1NSL6B-0004Pa-NM for ged-emacs-devel@m.gmane.org; Wed, 06 Jan 2010 02:54:12 +0100 Original-Received: from localhost ([127.0.0.1]:38229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSL6C-0007BD-04 for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2010 20:54:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSJMt-0002V7-Mr for emacs-devel@gnu.org; Tue, 05 Jan 2010 19:03:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSJMo-0002TC-5W for emacs-devel@gnu.org; Tue, 05 Jan 2010 19:03:18 -0500 Original-Received: from [199.232.76.173] (port=44607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSJMn-0002Sy-GD for emacs-devel@gnu.org; Tue, 05 Jan 2010 19:03:13 -0500 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:32559) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSJMd-00023n-KG; Tue, 05 Jan 2010 19:03:06 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o0602uK3024242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jan 2010 00:02:57 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o05NT9rX032193; Wed, 6 Jan 2010 00:02:55 GMT Original-Received: from abhmt014.oracle.com by acsmt357.oracle.com with ESMTP id 1285591981262736172; Tue, 05 Jan 2010 18:02:52 -0600 Original-Received: from dradamslap1 (/141.144.224.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Jan 2010 16:02:52 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqOXegQduxuysdqSh6I/fwFGsfzLQAAFk0Q In-Reply-To: <87ocl8gvcn.fsf@lola.goethe.zz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4B43D330.007B:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:119485 Archived-At: > > (save-excursion > > ... > > (set-buffer ...) > > (goto-char ...) > > ...) > > > > The problem with that code is that point in current buffer > > will be moved depending on whether the buffer we switch to > > is the same as the current buffer. > > And it will get restored in the current (original) buffer at > the end of the save-excursion. > > So it is not the save-excursion that is defeated by set-buffer, but > rather the goto-char which may be defeated by save-excursion. Exactly. But I think it's not helpful to speak here of anything being "defeated" by anything. The only thing defeated is the user's possible misconception of what should happen. Certainly, `set-buffer' does not undo or inhibit or interfere with the normal behavior of `save-excursion'; it cannot be said to "defeat" `save-excursion' in any way. And the `goto-char' works fine. There is nothing wrong with it, regardless of which buffer is the target of `set-buffer'. It's simply that `save-excursion' restores some previous state. But only after its body is finished. For the duration of the body, `save-excursion' has no effect. What happens inside a `save-excursion' is not an issue - `save-excursion' does not change the behavior of code inside it. And aside from non-local exits (e.g. `throw'), its body has no effect on the behavior of `save-excursion'. AFAIK. What's at issue here is only user understanding about `save-excursion', AFAICT. The problem is apparently that some users could forget or not know that `save-excursion' restores point and mark in the original buffer (only), along with restoring the current-buffer identity. So what? Some users forget or don't know that (setq a '(b)) doesn't necessarily create new list structure each time it is evaluated. Some users - including any of us - forget or don't know lots of things. This is an education problem. Compiler warnings can sometimes help with education, but only if they are (a) not too noisy, (b) accurate and precise, and (c) understandable. I see this warning as not helping but, at best, confusing users. If you think that byte-compile is clever enough to determine the places where it really should warn (certainly not every use of `set-buffer' inside `save-excursion'), then the message should refer the user to the explanation of `save-excursion' in the manual. The manual can point out the issue raised here, if it is indeed a common gotcha. But I doubt that byte-compile is that clever now or that it even could be made that clever. IMO the warning should simply be removed.