[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inefficient code in reftex-index.el

From: David Kastrup
Subject: Re: Inefficient code in reftex-index.el
Date: Tue, 07 Jun 2005 01:55:42 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> address@hidden (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]