Re: [ox] possible to modify org-export-document-properties OTG

[Rasmus <rasmus@gmx.us>]

Nicolas Goaziou <mail@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