Eric Abrahamsen <e...@ericabrahamsen.net> writes: > Nicolas Goaziou <n.goaz...@gmail.com> writes: > >> Hello, >> >> Eric Abrahamsen <e...@ericabrahamsen.net> writes: >> >>> 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. >> >> I didn't look closely into the issue, but I think the main reason is >> that Element parses headlines thoroughly, including all properties, >> scheduled keywords, which is not, by default, the case for >> `org-map-entries'. >> >> For most use-cases, you don't need the parser for headlines, as their >> grammar is context free. IOW, `org-element-parse-buffer' doesn't predate >> `org-map-entries'. > > Interesting, thanks! I think at first we were unsure if org-map-entries > was going to stay around in the long term, but it sounds like it's not > going anywhere.
Yes, thanks for the feedback, org-map-entries is very useful and powerful but I wasn't sure if its still a "first-class member" of Org-mode or already a bit deprecated. Nice to hear that it is going to stay. -- cheers, Thorsten
