Rasmus <ras...@gmx.us> writes:
> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>
>> 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").
I would add that, to be in that category, a keyword needs to be
supported by at least 3 major back-ends (among ASCII, HTML, ODT and
LaTeX).
>> 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.
The rule above is good enough to make a decision in most cases, IMO.
> I think keywords that are well-supported by Org-core should be there.
That doesn't contradict category 1.
> 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.
Do you mean KEYWORD and DESCRIPTION should also belong to category 1?
I'm not against it, but then, back-ends are required to support them
whenever possible.
> 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.
I don't want to create a third category (à la
`org-element-document-properties', which I'm trying to remove).
> We can't support SUBTITLE everywhere, 'cause it simply does not make sense
> (only in "text document producers" IMO).
That doesn't contradict category 1 either, as shown by EMAIL example.
> The support of SUBTITLE is:
>
> W/Emacs: support is 6/9
That's fine as there is no simple way to support SUBTITLE in the
3 back-ends left. Also, the "big four" support it.
> 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.
We are not maintaining the former and have no control over the latter,
so it doesn't matter.
Regards,
