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: Wed, 6 Jan 2010 00:57:27 -0800 Message-ID: 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><558DC61A9B3E4FF89CC53FF9DF7F7709@us.oracle.com> <87eim3hd14.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 1262768306 17565 80.91.229.12 (6 Jan 2010 08:58:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2010 08:58:26 +0000 (UTC) To: "'David Kastrup'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 06 09:58:11 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 1NSRiU-0000pY-IY for ged-emacs-devel@m.gmane.org; Wed, 06 Jan 2010 09:58:10 +0100 Original-Received: from localhost ([127.0.0.1]:51989 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSRiU-0002k0-CV for ged-emacs-devel@m.gmane.org; Wed, 06 Jan 2010 03:58:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSRiN-0002ih-RQ for emacs-devel@gnu.org; Wed, 06 Jan 2010 03:58:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSRiI-0002fe-DJ for emacs-devel@gnu.org; Wed, 06 Jan 2010 03:58:02 -0500 Original-Received: from [199.232.76.173] (port=54198 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSRiI-0002fV-53 for emacs-devel@gnu.org; Wed, 06 Jan 2010 03:57:58 -0500 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:34391) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSRiD-0000Tr-JV; Wed, 06 Jan 2010 03:57:53 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o068vnA5011662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jan 2010 08:57:51 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o068vmr5017783; Wed, 6 Jan 2010 08:57:49 GMT Original-Received: from abhmt005.oracle.com by acsmt356.oracle.com with ESMTP id 1288797361262768256; Wed, 06 Jan 2010 00:57:36 -0800 Original-Received: from dradamslap1 (/141.144.224.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Jan 2010 00:57:35 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqOp2uiikKUojZLSRiNWu41tjNVTQAAKQBw In-Reply-To: <87eim3hd14.fsf@lola.goethe.zz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4B44508D.015D: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:119510 Archived-At: > > Show me a single case (in existing code) where (save-excursion > > (set-buffer FOO) ...) wouldn't better be written some other way. > > That does not justify a bogus warning. > Show me a single case where > > (setq a ...) (setq a ...) > > wouldn't be better be written some other way (with "better" meaning a > completely subjective measure). Yet we don't warn about it. > We don't press matters of style lightly. > > Or more serious, a single case where > (sort xxx ...) or (nconc xxx ...) outside of a (setq xxx ...) wouldn't > better be written some other way. > We don't warn about those either. Yes, and besides that argument, and without arguing about the "best" style in which to code things, just what is inherently wrong or dangerous (meriting a warning) with code like the following, to do some work in other buffers yet return to the original buffer AND restore its point and mark? (save-excursion (set-buffer FOO) ; Pick up some info in FOO, & perhaps assign it to a var (set-buffer BAR) ; Calculate something in BAR, & perhaps record it too ... ) ; Use the gathered info to do something in the ; original buffer at the saved point. The Elisp manual says: "The `save-excursion' special form is the standard way to switch buffers or move point within one part of a program and avoid affecting the rest of the program. It is used more than 4000 times in the Lisp sources of Emacs." The _standard_ way to _switch buffers_ and/or move point. Imagine that. It of course does _not_ switch buffers on its own, which means that it is standard to use it with some buffer-changing command such as `set-buffer' (or `with-current-buffer' or ...). It is not the only way. It is not always the best way. But it is one way. And it has even been called "the standard" way. Since Day 1. The manual also says: "The way to designate a current buffer in a Lisp program is by calling `set-buffer'." _The way_. Again, that sounds pretty definitive, but the context tones that down a bit by mentioning some additional ways. None of those alternatives is presented as _the_ generally preferred way, however. No preference is indicated. The gist is that `save-excursion' + `set-buffer' is a not unreasonable way to switch buffers temporarily to do something without affecting the original context (current buffer, point, mark). A far cry, at least, from warning users that such code is somehow abhorrent or inherently unsafe. No one is arguing that one should always use `(save-excursion (set-buffer...)...)' in preference to other approaches. It's just that a good case for issuing a _warning_ for that has not been made. The only arguments made have been in terms of user misunderstanding or preferred coding style. And those things are better dealt with clearly, at sufficient length to promote understanding, in the Elisp manual.