Hello, Rasmus <ras...@gmx.us> writes:
> Is it possible to modify or extend org-export-document-properties on the > go? And would it be OK? `org-export-document-properties' is a defconst, which is computed from `org-element-document-properties', also a defconst. So, no, it isn't meant for that. Document properties are keywords where `org-element-context' is allowed to return an object. It doesn't make sense to add random keywords specific to some export back-ends to the list. > Or should org-element-parse-secondary-string be used with appropriate > limitations? For now, I suggest to use `org-element-parse-secondary-string'. > It would be useful 'cause it's an easy way to have a property parsed. In > ox-koma-letter.el it would make sense to make #+SUBJECT a document > property (ATM org-syntax isn't interpreted). In some backends it would > probably also make sense to make #+KEYWORDS parsed. I'm also working on a > patch to add #+SUBTITLE, which would also benefit from being easily added > as a document-property. You can always use `org-element-parse-secondary-string' on the keyword value and `org-export-data' or `org-export-data-with-backend' on it. At some point, I thought about adding a `parsed' behaviour to `org-export-options-alist' as a shortcut. Sadly, I cannot remember why I didn't implement the idea eventually. It may be related to `org-element-map', which couldn't map over data in such keywords, or the fact that it would be confusing wrt `org-element-context'. E.g., if we consider the two keywords #+TITLE: *boXld* #+PARSED_KÊYWORD_IN_SOME_BACKEND_IGNORED_IN_OTHERS: *boXld* in the former, `org-element-context' at "X" returns a `bold' object, in the latter, a `keyword' element. Note that I'm not arguing it should return a `bold' object in both cases, it really shouldn't, but it can be confusing and potentially trigger false bug reports. Regards, -- Nicolas Goaziou
