From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: How to find the headline matching a string Date: Tue, 03 Jun 2014 17:51:17 +0800 Message-ID: <877g4y723u.fsf@ericabrahamsen.net> References: <87bnuedl38.fsf@ericabrahamsen.net> <87ha45r9hi.fsf@gmail.com> <874n05e0ls.fsf@ericabrahamsen.net> <87r436mkgb.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrlKD-0004Yd-Ka for emacs-orgmode@gnu.org; Tue, 03 Jun 2014 05:48:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrlK8-0001QF-7C for emacs-orgmode@gnu.org; Tue, 03 Jun 2014 05:48:09 -0400 Received: from plane.gmane.org ([80.91.229.3]:37490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrlK8-0001QA-08 for emacs-orgmode@gnu.org; Tue, 03 Jun 2014 05:48:04 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WrlK2-0000nX-7M for emacs-orgmode@gnu.org; Tue, 03 Jun 2014 11:47:58 +0200 Received: from 123.123.23.56 ([123.123.23.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jun 2014 11:47:58 +0200 Received: from eric by 123.123.23.56 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jun 2014 11:47:58 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Cc: Nicolas Goaziou Thorsten Jolitz writes: > Eric Abrahamsen writes: > >> Thorsten Jolitz writes: >> >>> Chris Poole 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