[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inefficient code in xml.el
From: |
Kevin Rodgers |
Subject: |
Re: Inefficient code in xml.el |
Date: |
Mon, 06 Jun 2005 11:18:12 -0600 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041105) |
address@hidden wrote:
> Well, i get the point, but how an elisp-programmer should know this?!
>
> The manual says:
>
> - Function: match-data
> This function returns a newly constructed list containing all the
> information on what text the last search matched. Element zero is
> the position of the beginning of the match for the whole
> expression; element one is the position of the end of the match
> for the expression. The next two elements are the positions of
> the beginning and end of the match for the first subexpression,
> and so on. In general, element number 2N corresponds to
> `(match-beginning N)'; and element number 2N + 1 corresponds to
> `(match-end N)'.
>
> All the elements are markers or `nil' if matching was done on a
> buffer, and all are integers or `nil' if matching was done on a
> string with `string-match'.
>
> As always, there must be no possibility of intervening searches
> between the call to a search function and the call to `match-data'
> that is intended to access the match data for that search.
>
> (match-data)
> => (#<marker at 9 in foo>
> #<marker at 17 in foo>
> #<marker at 13 in foo>
> #<marker at 17 in foo>)
>
> What about to mention such inefficiency-problems in the documentation?!
> The manual only says "... Corresponds to ....". IMHO the documentation
> must mention the performnace-topic if it is so important you wrote in
> these postings!
Just change the first sentence to:
This function returns a newly constructed list of newly
allocated markers, containing all the information on what text
the last search matched.
A reference to the Markers node there might be useful. And this bit
from the Markers node should be emphasized:
Insertion and deletion in a buffer must check all the markers
and relocate them if necessary. This slows processing in a
buffer with a large number of markers.
--
Kevin Rodgers