From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: save-match-data woes Date: Mon, 25 Feb 2002 09:10:03 +0100 Message-ID: <20020225090007.B039.LEKTU@terra.es> References: <20020221115255.A397.LEKTU@terra.es> <200202221643.g1MGh3a30474@rum.cs.yale.edu> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: quimby2.netfonds.no 1014624917 30083 195.204.10.66 (25 Feb 2002 08:15:17 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 25 Feb 2002 08:15:17 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16fGI0-0007p7-00 for ; Mon, 25 Feb 2002 09:15:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fGFA-0001MZ-00; Mon, 25 Feb 2002 03:12:20 -0500 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fGCz-0001ET-00 for ; Mon, 25 Feb 2002 03:10:06 -0500 Original-Received: from jbarranquero (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id g1P8A2824658; Mon, 25 Feb 2002 09:10:02 +0100 Original-To: "Stefan Monnier" In-Reply-To: <200202221643.g1MGh3a30474@rum.cs.yale.edu> X-BkRandomSig-Folder: 3ade7ea7.mb\Emacs\Emacs-Devel\ X-Mailer: Becky! ver. 2.00.07 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1510 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1510 On Fri, 22 Feb 2002 11:43:03 -0500, "Stefan Monnier" wrote: > I think this is a wrong approach. The match-data need only be saved > in a few particular circumstances and I'd rather handle those cases > in a special way. Well, I'm not so sure about the "few particular circumstances". I think is bad for a function to arbitrarily change the match data and not saving it and not even documenting that it does modify it. That's bound to cause trouble somewhere far away, where perhaps the trouble won't be so easily connected with match data. I have no hard data, but my gut feeling is that you will end saving/restoring match-data in many places just to protect you against the relatively few functions that do not do that now. What if one of your elisp modules is safely using a function in another module and its maintainer just modifies slightly the implementation, using now pp-to-string where he didn't before? Probably you weren't saving match data because you didn't see the reason... and I fail to see *why* you should have any reason now. It is not you who changed anything. > For ielm, the problem is that the user might invoke any random command > between two inputs, so fixing M-p and M-n is not enough. You're right. In the case of ielm.el, your fix is much better than mine. (Unrelated:) On the matter of ielm, is there any objection to my patch of a few days back that makes ielm-prompt customizable and read-only? /L/e/k/t/u _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel