Re: Inefficient code in reftex-index.el

[Kim F. Storm]

David Kastrup <address@hidden> writes:

>     If INTEGERS (the optional first argument) is non-nil, always use
>     integers (rather than markers) to represent buffer positions.  In
>     this case, and if the last match was in a buffer, the buffer will get
>     stored as one additional element at the end of the list.
>
> Notice the last sentence.  This keeps the description for Element 2N
> and Element 2N+1 valid.
>
> I think that, if at all, the evaporate thingy should also occupy the
> last element on the list rather than the first.  We got enough
> inconsistency already as it is.

That's probably a good idea -- I'll give it a try.

>
>>> 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.
>
> Oh, it does?  I thought that it just recycled the CONS cells, but not
> the markers.

It used to do that, but my patch changed it to reseat the markers.

In any case, I didn't find any code which actually uses the REUSE
form of match-data, so that feature is pretty obscure already, so
I think we should just keep the original behavior of the REUSE arg.

>
>> In any case, to me, the match-data interface should not be
>> considered a user-level feature _at all_.
>
> There is no other interface into the number of accessible match
> strings (which might be nil) rather than
> (/ (length (match-data t)) 2).

That's still pretty inefficient -- I suggest that we introduce a new
function `match-count' to return that number.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk