org-mode

org-mode copied to clipboard

Properties are just a special case of drawers.

The following parses into Map Text Text

:PROPERTIES:
:DESCRIPTION: hello world
:END:

But the following does not,

:LOGBOOK:
CLOCK: [2021-04-30 Fri 11:04]
:END:

(The latter is to be used for time-tracking, cf. https://github.com/srid/orgself/issues/4)

---

It looks like the general syntax for drawers is as follows:

• :<NAME>: in first line, followed by
• zero or more lines of arbitrary text (how they are interpreted is dependent on <NAME>)
• :END: as the last line

---

Then I propose that we replace https://github.com/fosskers/org-mode/blob/3f6ff60d9ff0c8bdd569dac76a73200433fe2504/org-mode/lib/Data/Org.hs#L237

with

, sectionProps     :: M.Map Text Text
, sectionDrawers     :: (Text, Text)

As this library implements more drawer types, we can lift the unparsed drawer out of sectionDrawers into its own type. For example, when handling the clocking logbook,

, sectionProps     :: M.Map Text Text
, sectionLogbook :: M.Map Text OrgClock -- Probably not right type
, sectionDrawers     :: (Text, Text)

(Again, would be happy to take a stab at this depending on what the agreed upon spec is)

I'm not really sure about "M.Map Text OrgClock" (since each key can have different type). I personally am compelled to use GADTs and DSum to represent the various properties in LOGBOOK -- which would also allow making properties a sub-type of drawers -- but I realize you want to keep the library simple.

I'm in favour of adding specific, known drawers like the LOGBOOK on a case-by-case basis, although I won't be able to do this myself for the moment.

Some small nuances:

IIRC, LOGBOOK Logbook and logbook are all valid "logbook" identifiers (my parser the drawer title just is anything between two :s) so in the implementation, the key of the drawer must all be upper-cased or lower-cased for consistency.

Also, drawers can happen anywhere in an org-file. One of the problems with my current fork is that org-roam places PROPERTIES drawers at the top of an org-file which breaks current assumptions in this codebase.

I also use org-roam but haven't used this library to parse such files, but I'm not against moving in that direction.