From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: find-file-noselect needs save-match-data Date: Wed, 13 Jun 2007 20:33:54 +0200 Message-ID: <85tztbvh4d.fsf@lola.goethe.zz> References: <46643852.6070709@gmx.at> <46665AD7.7040706@gmx.at> <87k5ueq23m.fsf@kfs-lx.testafd.dk> <87myz8c10t.fsf@jurta.org> <18030.3441.204697.244518@rgrjr.dyndns.org> <87zm3515r4.fsf@jurta.org> <85k5u8x2gm.fsf@lola.goethe.zz> <87r6og6czf.fsf@catnip.gol.com> <85bqfkx0i5.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181759660 14920 80.91.229.12 (13 Jun 2007 18:34:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2007 18:34:20 +0000 (UTC) Cc: rms@gnu.org, miles.bader@necel.com, schwab@suse.de, emacs-devel@gnu.org, juri@jurta.org, miles@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 20:34:18 2007 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 1HyXfc-00014W-45 for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 20:34:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyXfb-0007tK-Do for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 14:34:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyXfX-0007t5-RO for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:34:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyXfV-0007st-F9 for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:34:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyXfV-0007sq-96 for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:34:09 -0400 Original-Received: from mail-in-04.arcor-online.net ([151.189.21.44]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HyXfS-0006Cf-Tj; Wed, 13 Jun 2007 14:34:07 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 6536B17F614; Wed, 13 Jun 2007 20:34:05 +0200 (CEST) Original-Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 207FC28EC66; Wed, 13 Jun 2007 20:34:05 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-065-130.pools.arcor-ip.net [84.61.65.130]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 8F2F01C3326; Wed, 13 Jun 2007 20:34:02 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 135B31C3E01D; Wed, 13 Jun 2007 20:33:54 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Wed\, 13 Jun 2007 13\:31\:49 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:72796 Archived-At: Stefan Monnier writes: >> Anyway, such a function should likely _return_ the corresponding >> match-data (rather than setting a global variable to it), and things >> like match-beginning should optionally take an argument for this >> particular match-data. > >> That is a good idea. If there is no match, it returns nil; if there >> is a match, it returns the match data. > > Then what's the advantage compared to using save-match-data? That it's reentrant... And that it does not touch the match data. The idea was to have a function that does not touch global data, yet delivers the full information. Now one problem here is that we don't want the delivery of information to be expensive, so consing together a list is probably not really the hottest idea. > This whole discussion started because people want to add > save-match-data everywhere and I pointed out that it's very rarely > necessary, and it can be costly (where the "it" is generating the > Lisp-level match data). The suggestion to have a specialized > string-match operation that preserves match-data was for performance > reasons, AFAICT, like fast_c_string_match. The main problem I currently see is that the current semantics and usage would want to have save-match-data used in places where actually nobody changes match-data. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum