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: Inefficient code in reftex-index.el Date: Tue, 07 Jun 2005 01:55:42 +0200 Message-ID: <858y1n2g75.fsf@lola.goethe.zz> References: <85slzv7j87.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 1118102328 15138 80.91.229.2 (6 Jun 2005 23:58:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2005 23:58:48 +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 01:58:45 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DfRSI-0005Cb-Pu for ged-emacs-devel@m.gmane.org; Tue, 07 Jun 2005 01:56:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfRYg-0006jb-M1 for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 20:03:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DfRXC-00069r-Ob for emacs-devel@gnu.org; Mon, 06 Jun 2005 20:01:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DfRX8-00066U-5i for emacs-devel@gnu.org; Mon, 06 Jun 2005 20:01:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfRX6-00064x-Uh for emacs-devel@gnu.org; Mon, 06 Jun 2005 20:01:29 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DfRUm-0002NP-3o for emacs-devel@gnu.org; Mon, 06 Jun 2005 19:59:04 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DfRQ3-0007qL-5g; Mon, 06 Jun 2005 19:54:11 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id ADC791C3DFFF; Tue, 7 Jun 2005 01:55:42 +0200 (CEST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 07 Jun 2005 00:24:49 +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:38207 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38207 storm@cua.dk (Kim F. Storm) writes: > storm@cua.dk (Kim F. Storm) writes: > >> >> Which brings me to the suggestion that we add an optional arg to >> set-match-data like this: >> >> (set-match-data list &optional destroy-markers) >> >> and change save-match-data to use it >> >> (defmacro save-match-data (&rest body) >> "Execute the BODY forms, restoring the global value of the match data. >> The value returned is the value of the last form in BODY." >> ;; It is better not to use backquote here, >> ;; because that makes a bootstrapping problem >> ;; if you need to recompile all the Lisp files using interpreted code. >> (declare (indent 0) (debug t)) >> (list 'let >> '((save-match-data-internal (match-data))) >> (list 'unwind-protect >> (cons 'progn body) >> '(set-match-data save-match-data-internal t)))) > > 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. 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), but it is hardly an element of beauty. Should not (match-data whatever '(evaporate marker1 marker2 ...)) also clean up the markers passed in for reuse? Anyway, allow me to throw a fit. The whole match-data thing was ugly previously, but this surely takes the cake, platter and all. At the very least, the INTEGERS argument should be renamed to something more in line with the new function. But I don't like that interface at all, really. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum