Question: How to honor scope-specific TODO keywords

[vidbina]

Hi @rasendubi,

Is there an idiomatic approach to update the options while parsing? There are a few todoKeywords defined as default and it is unclear how I idiomatically adapt these as I parse a text to allow for the detection of custom keywords.

For example, the following document is valid Org with support or multiple keywords as documented in https://orgmode.org/manual/Per_002dfile-keywords.html (it is technically part of the TODO extensions, so arguably not standard Org and therefore I can imagine that you may consider this out-of-scope for this project):

#+title: Engineering
#+TODO: TODO(t) IN_SCOPING WIP IN_DEV IN_TEST | DONE(d@) CANCELLED(c@)

* Prototype
#+TODO: TODO(t) | DONE(d)
#+TODO: REPORT(r) BUG(b) KNOWNCAUSE(k) | FIXED(f)
#+TODO: | CANCELED(c)

** DONE Scaffold basic app

** BUG Timeouts on large files

** IN_SCOPING Build basic collaborative editing functionality

Just the basics, not even rich-text at the time. 🤷🏿‍♂

* Infrastructure 
** TODO Provision database
** TODO Provision compute env

Keywords other than TODO and DONE don't get parsed as todoKeywords unless I set the options before I start to parse.

🎁 I would want the parser to adapt its keywords list based on what it reads from TODO, TYP_TODO and SEQ_TODO keywords throughout a document such that a section's own keywords are honored. Potentially, populate a stack as we propagate through the heading trees may be a way to go around it.

❓ Curious to hear your thoughts a) w.r.t facilitating this functionality and b) whether this feature fits within the scope of the project? Additionally, if you would be open to a PR for this, do you have any thoughts on how one should go ahead and implement this to fit well with you general vision for this project?

[rasendubi]

Definitely in the scope of the project. This is also closely related to #+OPTIONS as they also influence how file is parsed. The main challenge with these is that they can occur anywhere in the file. Options or todos might be specified on the last line of the file and they should still affect all the lines above. (In emacs, I believe they set buffer-local variables and re-fontify. That's why you have to C-c C-c when you change options line.) The easiest way to implement this in uniorg is to parse file twice. First time to extract keywords, and second—with options configured from the first parse.

[rasendubi]

Also notice that #+TODO is not scoped to a heading but to a file (the doc calls them "file-local").