Re: Month-week and quarter-week datetrees (RFC and package announcement)

[Jack Kamm <jackkamm@gmail.com>]

Ihor Radchenko <yantar92@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.