From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [ox, patch] #+SUBTITLE Date: Sun, 29 Mar 2015 15:13:32 +0200 Message-ID: <87bnjct08z.fsf@gmx.us> References: <87y4miv7y6.fsf@gmx.us> <87a8yxi0zf.fsf@nicolasgoaziou.fr> <87k2y1qfpi.fsf@gmx.us> <87d23sdtod.fsf@nicolasgoaziou.fr> <87oanct43z.fsf@gmx.us> <874mp4dkeb.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcD2H-0004O6-Fh for emacs-orgmode@gnu.org; Sun, 29 Mar 2015 09:13:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcD2E-000235-7p for emacs-orgmode@gnu.org; Sun, 29 Mar 2015 09:13:53 -0400 Received: from plane.gmane.org ([80.91.229.3]:60767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcD2E-00022o-0X for emacs-orgmode@gnu.org; Sun, 29 Mar 2015 09:13:50 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YcD2C-0002uX-2o for emacs-orgmode@gnu.org; Sun, 29 Mar 2015 15:13:48 +0200 Received: from 46.166.188.195 ([46.166.188.195]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Mar 2015 15:13:48 +0200 Received: from rasmus by 46.166.188.195 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Mar 2015 15:13:48 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou 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!