emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

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