emacs-devel
[Top][All Lists]
Advanced

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

Re: Inefficient code in reftex-index.el


From: Kim F. Storm
Subject: Re: Inefficient code in reftex-index.el
Date: Tue, 07 Jun 2005 13:28:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
>
>> 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.
>
> Look at replace-match-data in replace.el...

I see.  But that doesn't contradict my feeling that match-data
doesn't have to do anything special about markers in REUSE.

But we could make an optional arg RESEAT to match-data which
causes the markers in REUSE to be reseated to nowhere (if t),
or be freed if RESEAT equals `evaporate'.

>
> I think it was me that did that piece of prescient paranoia.
>
>>>> 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.
>
> No objection here.  No idea whether match-size would be more
> appropriate.  The C code is not really helpful deciding about that
> since it uses search_regs.num_regs and that is not suggestive of any
> sensible Lisp name.

IMO, match-count is better than match-size.

BTW, match-count != search_regs.num_regs, as match-data only
returns elements up to the last successful submatch.

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





reply via email to

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