From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: `save-excursion' defeated by `set-buffer' Date: Sun, 13 Mar 2011 09:18:34 +1100 Organization: Unlimited download news at news.astraweb.com Message-ID: <87ei6cj83p.fsf@rapttech.com.au> References: <4D792D16.1080900@easy-emacs.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299969651 13628 80.91.229.12 (12 Mar 2011 22:40:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Mar 2011 22:40:51 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Mar 12 23:40:47 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 1PyXUL-0006F0-0y for geh-help-gnu-emacs@m.gmane.org; Sat, 12 Mar 2011 23:40:45 +0100 Original-Received: from localhost ([127.0.0.1]:50411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyXUJ-0007XF-D3 for geh-help-gnu-emacs@m.gmane.org; Sat, 12 Mar 2011 17:40:43 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.astraweb.com!border5.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:w31pH+/IyxNu1ngCSX7CwTKu2HE= Original-Lines: 58 Original-NNTP-Posting-Host: 66ac3dde.news.astraweb.com Original-X-Trace: DXC=M6W[gJcH1W2h5BA 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:80042 Archived-At: Eli Zaretskii writes: >> From: Stefan Monnier >> Date: Fri, 11 Mar 2011 10:52:14 -0500 >> >> So (save-excursion (goto-char BAR)) is pretty much a no-op. >> >> But (save-excursion (set-buffer FOO) (goto-char BAR)) is either: >> - the same as (save-excursion (goto-char BAR)), in case FOO is already current. >> - an inefficient form of (with-current-buffer FOO (goto-char BAR)). >> I still haven't found any code out there where this behavior is what >> is actually wanted and expected by the programmer. >> >> In more than 90% of the cases, the intended meaning is >> (with-current-buffer FOO (goto-char BAR)) and the behavior if FOO is >> current (to additionally preserve point) is harmless, so the warning >> simply points out an inefficiency. >> >> In the remaining cases, FOO is almost always current, but when it's not >> the resulting behavior is a bug. I.e. the intended code is >> (with-current-buffer FOO (save-excursion (goto-char BAR))). > > Then how about changing the text of the warning to something like > > Warning: `save-excursion' will not preserve point in the other buffer > set by `set-buffer' > I'm not sure it is possible to get a really concise warning message here and the issue requires more explination than is possible in a warning message. My suggestion would be to add the word 'possibly' and perhaps add a reference to a relevant section in the manual i.e. Warning: save-excursion possibly defeated by set-buffer. See . The above would be preferrable over longer warning messages, especially messages that really only describe the behavior of save-excursion as that doesn't really add anything the programmer probably didn't already know. There are other warning which reference the manual (such as the one concerning old style backquotes), so it seems like a consistent approach. Adding the word possibly emphasises this is a warning and not an error and could be legitimate. Issuing a warning with a reference to a relevant section of the manual would allow the programmer to see the warning, lookup that section and get a more in-depth explination about the possible situations and why either save-excursion is not doing what the programmer expects or is inefficient and would be better coded using with-current-buffer etc. They can then decide how relevant the warning is and adapt their code appropriately. Tim -- tcross (at) rapttech dot com dot au