Re: [O] How to find the headline matching a string

[Eric Abrahamsen]

Thorsten Jolitz <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>
>> Thorsten Jolitz <address@hidden> writes:
>>
>>> Chris Poole <address@hidden> writes:
>>>
>>>> Eric Abrahamsen:
>>>>> the `org-map-entries' function can be given a scope of 'agenda
>>>>
>>>> That worked perfectly, thanks. Here's what I ended up with:
>>>>
>>>> (org-map-entries (lambda ()
>>>> (when (equal title (org-get-heading t t))
>>>> (org-entry-put (point) "TODO" "DONE")))
>>>> tag 'agenda)
>>>
>>> As much as I like the powerful `org-map-entries', I wonder if it will
>>> coexist with `org-element-map' in the future, since it does not use the
>>> new parser. 
>>>
>>> Whats the recommendation here? Should one rather use 
>>>
>>> ,-----------------------------------------------------------
>>> | (org-element-map (org-element-parse-buffer) 'headline (lambda () ...))
>>> `-----------------------------------------------------------
>>>
>>> nowadays, or do both functions serve different purposes, or is it just a
>>> matter of taste?
>>
>> Interesting! I wasn't even aware of org-element-map, thanks for that.
>> Obviously I don't know the answer to your question, but they do seem to
>> do very similar things. On the other hand, `org-element-map' won't do
>> multiple files, and if you want to restrict to certain elements you have
>> to do the matching logic yourself (as opposed to `org-map-entries's
>> agenda-style search string).
>>
>> I'd be curious, too, to hear if `org-map-entries' is going to get EOL'd
>> at some point. I suppose it's safe so long as `org-scan-tags' remains
>> the heart of the agenda process.
>>
>> Here's my stab at two roughly equivalent functions, one using
>> org-element, the other older function. Just for the hell of it I tried
>> using "benchmark" to profile them, but have no idea if the results mean
>> much of anything. Most importantly, I don't really know if
>> `org-element-parse-buffer' ends up using the cache or not -- I assume
>> not.

> This is interesting too - and a bit surprising. On my machine, the
> org-element based function takes almost 4 times as long as the
> org-map-entries based function:

I guess it shouldn't be too surprising -- the org element stuff is
completely parsing the entire buffer on every pass. The other function
probably boils down to passing a few targeted regexps over the buffer.
I've sneakily cc'd Nicolas to see what he thinks. My guess is we could
replace the call to org-element-parse-buffer with something that
creates/accesses the cached version of the parse tree, and things would
go much more swiftly.

E