From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: `save-excursion' defeated by `set-buffer' Date: Sun, 13 Mar 2011 11:22:50 -0700 Message-ID: <9F726D3B418A4DB6BF58058E2A8C880D@us.oracle.com> References: <4D792D16.1080900@easy-emacs.de> <83y64ksoik.fsf@gnu.org> <4D7BC2D8.8080909@easy-emacs.de> <4d7c335d$0$23757$14726298@news.sunsite.dk> 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 1300040612 12384 80.91.229.12 (13 Mar 2011 18:23:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2011 18:23:32 +0000 (UTC) To: "'Uday Reddy'" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 13 19:23:25 2011 Return-path: Envelope-to: geh-help-gnu-emacs@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 1Pypwq-0007wq-U3 for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Mar 2011 19:23:25 +0100 Original-Received: from localhost ([127.0.0.1]:52293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pypwq-0002ov-3a for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Mar 2011 14:23:24 -0400 Original-Received: from [140.186.70.92] (port=50091 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PypwS-0002of-Iv for help-gnu-emacs@gnu.org; Sun, 13 Mar 2011 14:23:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PypwR-0006s8-1M for help-gnu-emacs@gnu.org; Sun, 13 Mar 2011 14:23:00 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:31454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PypwQ-0006rX-EZ for help-gnu-emacs@gnu.org; Sun, 13 Mar 2011 14:22:59 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2DIMsYM013045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Mar 2011 18:22:55 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 p2DIMrv5006121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Mar 2011 18:22:54 GMT Original-Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2DIMr5f005527; Sun, 13 Mar 2011 13:22:53 -0500 Original-Received: from dradamslap1 (/10.159.54.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Mar 2011 11:22:53 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4d7c335d$0$23757$14726298@news.sunsite.dk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvhMIENHiaNMuLaR/Gb1EwaxlF90QAUdjEg X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D7D0B7E.0137,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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:80062 Archived-At: > > But this has already been expressed (by several people), > > and rejected, in various discussions in emacs-devel@gnu.org. > > I believe I was the one that last raised it in emacs-devel and, after > the explanations from Stefan Monnier and Stephen Turnbull, I was > satisfied. I told you quite explicitly that I was satisfied. So? As I said, the warning was discussed, and getting rid of it was rejected. You are convinced that that's a great decision; I am not. No way of knowing what most people felt or feel, and it doesn't matter because polls are not taken anymore when deciding... (Poor Emacs.) > > IMO, this warning has produced _far_ more confusion than it > > has eliminated. And that will no doubt continue to be the > > case going forward. > > Yes, I agree that this saga will continue for quite some time. But I > wouldn't say that the warning has produced all this confusion. The > confusion about how to use save-excursion correctly has existed for a > long time and continues to exist. The warning is the > messenger, not the cause of the confusion. I'm not convinced of the existence of this bogeyman about mass confusion concerning how to use `save-excursion'. I don't see such confusion. But it's pretty _obvious_ that the warning message has produced a colossal amount of confusion. Everybody and her brother has a different understanding of what the "danger" might be. > > FWIW, I also agree with Andreas that a "warning" is for > > something serious. A warning is not the same thing as in > > informative message. A warning _warns_ you about potential > > danger/damage. Alarmism eventually results in the Chicken > > Little effect (aka Boy Cries "Wolf!"). > > This particular warning is in the 'suspicious category. > It signals that the code is suspicious. Only if you think that using `save-excursion' with `set-buffer' is suspicious, which in general it is not. Wrt the supposed danger, David K replied this to Stefan (who replied to me, defining the danger) http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00588.html: >>> 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 >>> ... >>> ) >> >> What is dangerous about it is that dependong on which buffer is current >> before executing this code, the point-saving will either do something >> or nothing. > > Wrong. It will always restore the _original_ buffer and its point on > exit of the save-excursion form. David is correct of course. And Stefan's explanation of the "danger" does not indicate any danger, in any case. Where's the beef? > I for one would be very wary of using anybody's code that generates > such warnings. That is precisely one of the problems created by this misguided message. Users get freaked out seeing WARNINGs when they byte-compile the code. They don't understand the message (even seasoned developers differ in their guesses as to its meaning), and the unknown scares them. Even Stefan admits that the compiler is incapable of issuing such warnings only when the code is in fact problematic in his eyes. In plain English, it's stupid and warns about situations that even Stefan admits are not a problem. And much of the `save-excursion' code that he would consider problematic is in fact typically safe, sound, and sure. IOW, the warnings are all over the map - "tales told by an idiot, full of sound and fury, signifying nothing". Whether or not every use of `save-excursion' with `set-buffer' is stylistically neat or is the best choice in terms of software engineering is a different matter. And it is a matter that is not handled discriminately by this message, in any case. > The warnings would signal to me that the developers have not > taken care to use the programming language correctly. If they automatically signal that to you, then I would suggest that you might not have taken sufficient care to learn the programming language correctly. ;-) More seriously, RMS et al who created `save-excursion' were not idiots. They explicitly designed it to save and restore which buffer is current, in addition to its point and mark. Why, do you suppose? And most users of it over the years have used it well - without any warnings. If you automatically think that such a warning indicates bad code or inadequate knowledge of Emacs Lisp then you are jumping to a wild, indiscriminate conclusion, IMO. > They have produced code that happens to work but > could break easily when pulled and stretched. You cannot deduce that from the warnings issued. They might have; they might not have. Not every use of `save-excursion' with `set-buffer' indicates fragile, messy, or otherwise unwise code. Far from it. You yourself mentioned zillions of such uses in the code you inherited, only a tiny minority of which you felt needed correcting. And you certainly didn't need a warning for each occurrence in order to search your code for possible improvements.