[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> 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
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
