From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Inefficient code in reftex-index.el Date: Tue, 07 Jun 2005 10:46:15 +0200 Message-ID: References: <85slzv7j87.fsf@lola.goethe.zz> <858y1n2g75.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1118135432 25285 80.91.229.2 (7 Jun 2005 09:10:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Jun 2005 09:10:32 +0000 (UTC) Cc: Carsten Dominik , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 07 11:10:17 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dfa66-00021d-2y for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2005 11:10:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfaCa-0003s5-3s for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2005 05:16:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dfa2v-0000qL-6d for emacs-devel@gnu.org; Tue, 07 Jun 2005 05:06:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dfa2p-0000nf-7j for emacs-devel@gnu.org; Tue, 07 Jun 2005 05:06:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dfa2n-0000Pd-CF for emacs-devel@gnu.org; Tue, 07 Jun 2005 05:06:45 -0400 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DfZmU-00065b-I2; Tue, 07 Jun 2005 04:49:54 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepa.post.tele.dk (Postfix) with SMTP id D0CEF47FEDE; Tue, 7 Jun 2005 10:45:52 +0200 (CEST) Original-To: David Kastrup In-Reply-To: <858y1n2g75.fsf@lola.goethe.zz> (David Kastrup's message of "Tue, 07 Jun 2005 01:55:42 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:38232 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38232 David Kastrup writes: >> I made the change slightly different to avoid adding another arg to >> Fset_match_data, which causes problems at C level. Instead, if first >> arg to match-data is 'evaporate', set-match-data will eventually free >> markers on the resulting list... > > So if INTEGERS is 'evaporate, we don't get integers but markers, and > those will be unseated at restore time. Right -- either you want integers or you want markers (that evaporates). There is no ambiguity in that respect! > > In addition, the list will get prolonged by one additional member. > This is probably not too tragic since I don't see anybody else > accessing a data structure created with (set-match-data 'evaporate), That's (match-data 'evaporate)... > but it is hardly an element of beauty. The new interface is fully backwards compatible -- so unless the user specifies 'evaporate, the list is formatted exactly as it was before. > Should not > (match-data whatever '(evaporate marker1 marker2 ...)) also clean > up the markers passed in for reuse? It should, yes. Currently, it just reseats the markers on the list. > Anyway, allow me to throw a fit. The whole match-data thing was ugly > previously, but this surely takes the cake, platter and all. What are the alternatives? I can add new optional arguments to both match-data and set-match-data to indicate what to do with markers in the REUSE and LIST arguments. I can do that if people think it is better/cleaner. The drawback is that it requires more changes at the C-level -- but it may actually clean-up a few things, so perhaps it would be good... In any case, to me, the match-data interface should not be considered a user-level feature _at all_. The user level feature is save-match-data, which does not (in principle) allow the user to mess with the saved data. And in that respect, nobody should really care about what the format of the match data is. IMO, the byte-compiler should warn about using match-data. > > At the very least, the INTEGERS argument should be renamed to > something more in line with the new function. I will do that, if the current interface is acceptable. > But I don't like that > interface at all, really. I'm not excited about it either... but it does the job. -- Kim F. Storm http://www.cua.dk