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).
That's simple enough and easy to test. >> 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. At the moment they are. They lack ascii support, but at least keywords should be supported in ascii eventually IMO (but that's another thread). So I would keep them. The documentation explicitly states which backend these keywords are supported by. >> 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). This category would not exists in the code. It would simply be a classification that exists in the manual. I would be a hack to not maintain "no. of backend that support SOME_KEYWORD" different places to maintain documentation for SOME_KEYWORD. Anyway, the above is fine so let's use that. —Rasmus -- Summon the Mothership!