From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: save-excursion again Date: Fri, 18 Jun 2010 09:51:08 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1276869088 6177 80.91.229.12 (18 Jun 2010 13:51:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Jun 2010 13:51:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 15:51:24 2010 connect(): No such file or directory 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 1OPbyZ-00009a-Go for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 15:51:19 +0200 Original-Received: from localhost ([127.0.0.1]:37995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbyZ-0002fS-0I for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 09:51:19 -0400 Original-Received: from [140.186.70.92] (port=59705 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbyR-0002do-S1 for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:51:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPbyQ-0003Xs-7t for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:51:11 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:29378 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPbyQ-0003Xe-5e for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:51:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADAXG0xLd+Hj/2dsb2JhbACfDnLBeIUbBI0Ygx0 X-IronPort-AV: E=Sophos;i="4.53,439,1272859200"; d="scan'208";a="68347410" Original-Received: from 75-119-225-227.dsl.teksavvy.com (HELO pastel.home) ([75.119.225.227]) by ironport2-out.pppoe.ca with ESMTP; 18 Jun 2010 09:51:09 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id CD6DE7F26; Fri, 18 Jun 2010 09:51:08 -0400 (EDT) In-Reply-To: (Uday S. Reddy's message of "Fri, 18 Jun 2010 08:42:31 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:126156 Archived-At: > I am just catching up belatedly with this issue of save-excursion getting > defeated by set-buffer. Here is my understanding. Please let me know if > I am missing anything. If I have a piece of code like this that runs > in a buffer A: > (save-excursion > (set-buffer B) > ....X.... > ) > then: > - if the code X has no possibility of getting back to the buffer A and > moving point, then save-excursion can be replaced by save-current-buffer > (and the byte compiler gives you a brownie point). Yes. > - if the code X has a possibility of getting back to the buffer A and moving > around, then save-excursion should stay (despite getting smacked by the byte > compiler). It's actually slightly more subtle than that, because it depends on what you want to happen when you "get back to A and move around": it depends on whether or not you want the movement in A to be undone when you exit this code. If you do want to undo this movement, then indeed your `save-excursion' and your `set-buffer' are fundamentally unrelated (they just happen to be next to each other by chance) and the byte-compiler warning is in error. This is very rare in my experience (contrary to the case where the correct code is (with-current-buffer B (save-excursion ....)), which tho not common, has happened a few times). > So, every time we want to please the byte compiler, we need to > prove a little theorem to the effect that the code X doesn't enter the > buffer A? (No doubt some of these theorems will be obvious.) Indeed. The problem being that the precise semantics of such a construction is pretty subtle, so the byte-compiler can't do the proof for you. In some cases the proof is easy (e.g. there's no movement at all in that piece of code), but often it's very difficult (tho my experience might be made worse since I usually make such changes to code with which I'm not familiar). My approach is to basically replace all such code with just `with-current-buffer', then let users find the counter examples. Stefan