From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: find-file-noselect needs save-match-data Date: Thu, 14 Jun 2007 10:36:15 -0400 Message-ID: References: <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> <85tztbvh4d.fsf@lola.goethe.zz> <4670E6E4.3010906@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181831834 11387 80.91.229.12 (14 Jun 2007 14:37:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2007 14:37:14 +0000 (UTC) Cc: rms@gnu.org, schwab@suse.de, emacs-devel@gnu.org, juri@jurta.org, miles@gnu.org, miles.bader@necel.com To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 14 16:37:11 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 1HyqRi-00042y-Pf for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2007 16:37:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyqRi-0004Kj-9j for ged-emacs-devel@m.gmane.org; Thu, 14 Jun 2007 10:37:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyqRd-0004J0-8k for emacs-devel@gnu.org; Thu, 14 Jun 2007 10:37:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyqRZ-0004ET-7B for emacs-devel@gnu.org; Thu, 14 Jun 2007 10:37:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyqRZ-0004EG-1r for emacs-devel@gnu.org; Thu, 14 Jun 2007 10:37:01 -0400 Original-Received: from tomts13.bellnexxia.net ([209.226.175.34] helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HyqRA-0001aD-3Q; Thu, 14 Jun 2007 10:36:41 -0400 Original-Received: from pastel.home ([70.55.143.156]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070614143615.JOGB13954.tomts13-srv.bellnexxia.net@pastel.home>; Thu, 14 Jun 2007 10:36:15 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 24D6A7F83; Thu, 14 Jun 2007 10:36:14 -0400 (EDT) In-Reply-To: <4670E6E4.3010906@gmx.at> (martin rudalics's message of "Thu\, 14 Jun 2007 08\:57\:40 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Solaris 8 (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:72860 Archived-At: >> 2 - around code that needs to be run after string-match but before match-end > I fail to understand this. >> and of which we do not know that it leaves the match-data unaffected. >> This may be unnecessary because the code may in fact preserve the >> match-data even though you don't know it. >> >> So although number 1 may be an unnecessary use of save-match-data, I find >> it's usually useful/necessary. Number 2 OTOH can often turn out to be >> unnecessary. Luckily number 2 is very rarely needed because in most cases >> it's easier to restructure your code such that save-match-data is not needed >> any more. > Saving match-data is needed if the index for accessing match-data is > known only after performing a second match operation like in Yes, this is the number 2 I'm thinking of. >> So I don't see current usage as problematic w.r.t efficiency. > The info.el examples in my earlier mail seem to contradict this. I'm not saying it can't be misused. But using it right isn't that hard. The info.el example should be fixed. >> The only real problem with it is that people tend to not know/understand it >> and are thus tempted to complain that most functions need to be wrapped in >> save-match-data, which then leads to long discussions such as this one. >> Maybe we should make the convention more prominent by adding it to the >> docstring of save-match-data? > We probably should remove bad uses of `save-match-data' from Emacs code > in the first place. Agreed. As for removing most uses of save-match-data from files.el, I could agree. I probably have argued against most of the ones I've seen added there, but usually the other side wins because "well, it can't hurt to add it just here". So little by little it creeps in. Stefan