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. > > (defun my-find-title-element-map (title) > (interactive "sTitle: ") > (let ((files (org-agenda-files)) > found) > (dolist (f files) > (with-current-buffer (org-get-agenda-file-buffer f) > (org-element-map (org-element-parse-buffer 'headline) > 'headline > (lambda (hl) > (when (string= title (org-element-property :title hl)) > (push (move-marker (make-marker) > (org-element-property :begin hl)) > found)))))) > found)) > > > (defun my-find-title-entries-map (title) > (interactive "sTitle: ") > (let (found) > (org-map-entries > (lambda () > (when (string= title (org-get-heading t t)) > (push (move-marker (make-marker) > (line-beginning-position)) > found))) > nil 'agenda) > found)) > > (benchmark-run 100 (my-find-title-element-map "Unique Heading Text")) > => (164.576821235 142 23.892782392000186) > > (benchmark-run 100 (my-find-title-entries-map "Unique Heading Text")) > => (58.111630133 36 6.047778745000016)
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: #+BEGIN_SRC emacs-lisp (defun my-find-title-element-map (title) (interactive "sTitle: ") (let ((files (org-agenda-files)) found) (dolist (f files) (with-current-buffer (org-get-agenda-file-buffer f) (org-element-map (org-element-parse-buffer 'headline) 'headline (lambda (hl) (when (string= title (org-element-property :title hl)) (push (move-marker (make-marker) (org-element-property :begin hl)) found)))))) found)) #+END_SRC #+results: : my-find-title-element-map #+BEGIN_SRC emacs-lisp (defun my-find-title-entries-map (title) (interactive "sTitle: ") (let (found) (org-map-entries (lambda () (when (string= title (org-get-heading t t)) (push (move-marker (make-marker) (line-beginning-position)) found))) nil 'agenda) found)) #+END_SRC #+results: : my-find-title-entries-map #+BEGIN_SRC emacs-lisp :results raw (benchmark-run 30 (my-find-title-element-map "Unique Heading Text")) #+END_SRC #+results: (160.439753043 735 76.66140414599985) # => (164.576821235 142 23.892782392000186) #+BEGIN_SRC emacs-lisp :results raw (benchmark-run 30 (my-find-title-entries-map "Unique Heading Text")) #+END_SRC #+results: (37.973595622000005 123 12.137436705999733) # => (58.111630133 36 6.047778745000016) -- cheers, Thorsten