[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Month-week and quarter-week datetrees (RFC and package announcement)
From: |
Jack Kamm |
Subject: |
Re: Month-week and quarter-week datetrees (RFC and package announcement) |
Date: |
Mon, 30 Dec 2024 08:20:28 -0800 |
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.