Re: Inefficient code in reftex-index.el

[Kim F. Storm]

David Kastrup <address@hidden> 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 <address@hidden> http://www.cua.dk