Hi,

I've added a patch that address the code problems, but not the
documentation issues, as the solution is still unclear.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> But de facto KEYWORDS and DESCRIPTION were also only supported in some
>> backends.  I think it's more convenient to have these type of keywords in
>> one place.  But I don't feel strongly about this.
>
> I would like to keep a clear and somewhat future-proof rule about this:
>
>  1. A keyword a user can expect to find in all back-ends where it makes
>     sense should be defined in "ox.el". To put it differently, it can be
>     considered as a bug if a back-end could /simply/ support a keyword
>     in this category but doesn't. Keywords in this category are to be
>     documented in (info "(org)Export settings").
>
>  2. Other keywords are defined in their respective back-end, and
>     documented in their respective chapter in the manual.
>
> As a non-trivial example, consider :email. You can expect it to produce
> something sensible in any back-end. Yet, "ox-icalendar" doesn't use it.
> It still belongs to first category.
>
> If we support SUBTITLE everywhere it makes sense, it might be worth
> adding it to the first category. Actually, considering the rule above,
> I even lean towards adding it to that category. WDYT?

I think it's hard to make a clear-cut rule.  I think keywords that are
well-supported by Org-core should be there.  From a user perspective, I
think it should be close to TITLE.  Further, putting it there also signal
to external writers, e.g. ox-reveal, that they should now try to support
it.  I think SUBTITLE, KEYWORD, and DESCRIPTION is within the same
category and should be treated the same.

We could add a subsection with "text document properties" which are
keywords that are supported by the set: {ox-html, ox-ascii, ox-odt,
ox-latex}.  These would be sort of 1½ class citizens.

We can't support SUBTITLE everywhere, 'cause it simply does not make sense
(only in "text document producers" IMO).

The support of SUBTITLE is:

    W/Emacs: support is 6/9
    W/Contrib: support is 8/20
             - BTW: ox-groff seems to have some support for subtitles, but
               I'm not sure how this works, so I haven't tried to unify
               it.
             - I guess it could be added to ox-rss could support it.  Atom
               seems to support subtitle, but it does not seem rss 2.0 has
               it in its definition...  I don't know the details of RSS
               well.
    W/"the wild": for all I know the limit of the fraction is zero.

> Also, I'm going to implement the `parse-object' and `parse-element'
> behaviour we discussed in another thread, and remove
> `org-element-document-properties' (and the relative
> `org-export-document-properties') altogether. This will remove a useless
> distinction among keywords: two categories are enough.

I think this sounds very cool.  It will allow us to remove a lot of
"low-level" details from file with additional parsed keywords.

> As a side-effect, however, `org-element-context' will not show objects
> when called on TITLE and al, but that might be a good thing actually
> (there are objects in there only during export and only if considered
> export back-end makes use of them).

As mentioned, it's fine with me and nobody else complained so I think
there's no need to worry.

>>>   (and formatted-subtitle ...)
>>
>> Can you explain why (and ⋯) should be used here?
>
> It makes more obvious you are expecting a return value. `when' is
> preferred for side effects. However, this is not a hard rule, since

Thanks for the example.

—Rasmus

-- 
Don't panic!!!