Re: Inefficient code in reftex-index.el

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> 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.

Anyway, match-data states somehing like

    match-data is a built-in function in `src/search.c'.
    (match-data &optional INTEGERS REUSE)

    Return a list containing all info on what the last search matched.
    Element 2N is `(match-beginning N)'; element 2N + 1 is `(match-end N)'.
    All the elements are markers or nil (nil if the Nth pair didn't match)
    if the last match was on a buffer; integers or nil if a string was matched.
    Use `store-match-data' to reinstate the data in this list.

    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.

>> 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.

> 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).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum