Ihor Radchenko <yanta...@posteo.net> writes: >> + ;; Support the old way of tree placement, using a property >> + (let ((prop (and legacy-prop (org-find-property legacy-prop)))) >> + (if prop >> + (progn >> + (goto-char prop) >> + (org-narrow-to-subtree) >> + (setq tree (car (org-element-contents >> (org-element-parse-buffer 'headline))))) >> + (setq tree (org-element-parse-buffer))))) > > Why do you need object granularity by default (second call to > `org-element-parse-buffer')? > Also, more importantly, do you have to run the full parsing here? Maybe > utilize `org-element-cache-map' instead? Full parsing is going to be > much slower.
We don't need object granularity, that was an oversight on my part -- should have specified headline granularity. Does `org-element-cache-map' traverse elements in the order they're in the buffer? That is something we need for this. On my working branch I have an earlier commit that implements many of the improvements here but using the old regexp search way instead of the org-element way. Would it be worth reverting to that point? Specifically, the new `org-datetree-find-create-entry' that allows for nested years/quarters/months/weeks/days is still pretty straightforward to implement in the regexp approach. The more general `org-datetree-find-create-hierarchy' (that allows elisp hackers to build new kinds of datetrees) might be trickier without org-element, but we could also defer that for future work.
