From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: find-file-noselect needs save-match-data Date: Thu, 14 Jun 2007 08:57:07 +0200 Message-ID: <4670E6C3.7070505@gmx.at> 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=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1181804531 8716 80.91.229.12 (14 Jun 2007 07:02:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2007 07:02:11 +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 Thu Jun 14 09:02:08 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 1HyjLK-0002gN-5t for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2007 09:02:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyjLJ-0000M3-ND for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2007 03:02:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyjKx-0000E8-MY for emacs-devel@gnu.org; Thu, 14 Jun 2007 03:01:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyjKw-0000DX-OK for emacs-devel@gnu.org; Thu, 14 Jun 2007 03:01:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyjKw-0000DI-H8 for emacs-devel@gnu.org; Thu, 14 Jun 2007 03:01:42 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1HyjKv-0002Ik-9e for emacs-devel@gnu.org; Thu, 14 Jun 2007 03:01:41 -0400 Original-Received: (qmail invoked by alias); 14 Jun 2007 07:01:39 -0000 Original-Received: from N870P005.adsl.highway.telekom.at (EHLO [62.47.52.165]) [62.47.52.165] by mail.gmx.net (mp058) with SMTP; 14 Jun 2007 09:01:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18emXRODgQeETibEYZz0bsHS6U5H2vSG58qby0066 joIJO7oUzQFNqK User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-kernel: Linux 2.6 (newer, 1) 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:72832 Archived-At: > Then what's the advantage compared to using save-match-data? 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). Yes, I proposed to add `save-match-data' to a variety of file handling functions at the outermost level. The main reason for my proposal was to introduce some sort of consistency among functions in files.el with respect to saving match-data. If you proposed to remove _all_ instances of `save-match-data's from files.el instead, you get my 100% agreement. ISTR also that I was the first in this thread to mention that saving `match-data' is expensive. If we really cared about this we could start right in files.el. The following instance in `abbreviate-file-name' (save-match-data (string-match "^[a-zA-`]:/$" filename))))) should be replaced by binding the outcome of (match-string 1) of the previous string-match around it. Though using (fast-string-match "^[a-zA-`]:/$" filename)))) instead would be clearer and make such binding unnecessary ;-) > The suggestion to have a specialized string-match operation that preserves > match-data was for performance reasons, AFAICT, like fast_c_string_match. It was my suggestion to introduce - on the Lisp level - somthing like fast_string_match. My motivation was completely different though: Code using that function should reassure the reader that there would be no need to save match-data around it. It goes without saying that a "fast" string matching function should return the same value as `string-match' and _not_ `match-data'. I still believe that people spend more valuable time _thinking_ about whether match-data should be saved in a specific circumstance than when it is actually saved on their computer. Look at info.el: In `Info-dir-remove-duplicates' we have (while (re-search-forward "^\\(\\w.*\\)\n\\*" limit t) (when (if re (save-match-data (string-match re (match-string 1))) (equal name (match-string 1))) and in `Info-fontify-node' (cond ((save-match-data (looking-back "\\