Thorsten Jolitz <tjol...@gmail.com> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> Thorsten Jolitz <tjol...@gmail.com> writes: >> >>> Chris Poole <li...@chrispoole.com> 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
