Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > 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.
I think something like SUBJECT in ox-koma-letter makes sense. But what I'm really after is an "easy" way to control org-export-data from the backend definition. >> Or should org-element-parse-secondary-string be used with appropriate >> limitations? > > For now, I suggest to use `org-element-parse-secondary-string'. Why I don't like this is that it feels quite low-level (purely emotional) (org-export-data (oe-parse-2nd-string ⋯) ⋯) > At some point, I thought about adding a `parsed' behaviour to > `org-export-options-alist' as a shortcut. Presumably you'd want to be able to toggle it for elements of export-options. > 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_KYWORD_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. I don't understand why an export setting would affect an element interpretation such as org-element-map. Probably I have something different in mind than you. –Rasmus -- However beautiful the theory, you should occasionally look at the evidence