The combination of OrgKeyword and OrgTimeStamp might be worth its own entity "OrgPlanningSpec" or similar

[bgro]

When doing C-c C-s and C-c C-d on an org section, Orgmode will place both dates on the same line:

** TODO Understand how to use `https://github.com/amake/org_parser`
DEADLINE: <2025-01-06 Mon> SCHEDULED: <2025-02-03 Mon>

org_parser will recognise this as a OrgPlanningLine with children [OrgKeyword, OrgContent],
where the OrgContent is

[OrgPlainText, OrgSimpleTimestamp, OrgPlainText, OrgKeyword, OrgPlainText, OrgSimpleTimestamp]

thus making the SCHEDULED: specification somehow a part of the DEADLINE specification, whereas the two specs are conceptually on the same level. One could argue that the combination of a keyword and a timestamp should be its own entity, say OrgPlanningSpec or similar and the example above should be parsed into an OrgPlanningLine with children

[OrgPlanningSpec, OrgPlainText, OrgPlanningSpec, OrgPlainText]

and the OrgPlanningSpec with children

[OrgKeyword, OrgPlainText, OrgSimpleTimestamp]

But such a change is likely to break things for applications that work with the current way of parsing planning lines. It is just something I noticed when playing around with the parser, so I thought I might as well document it. Feel free to close this issue without any further action!

[amake]

Thanks for pointing this out. I agree that the current parse result is not good, and your suggestion is better.

I'm only aware of two applications that use org_parser (through org_flutter). One is Orgro, which is the primary use case for both org_parser and org_flutter. Orgro doesn't (yet) have any logic that requires understanding an OrgPlanningSpec, but it could in the future.

The other application is, as I understand it, using org_flutter for display only, and probably wouldn't be bothered by a change in the AST to improve this.

When (if) I get around to fixing this I will happily break compatibility and simply update org_flutter in lock-step, as has been my habit so far.