From: Nicolas Goaziou <email@example.com>
To: Rasmus <firstname.lastname@example.org>
Subject: Re: [ox, patch] #+SUBTITLE
Date: Tue, 31 Mar 2015 12:18:38 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (email@example.com's message of "Mon, 30 Mar 2015 12:35:34 +0200")
Rasmus <firstname.lastname@example.org> writes:
> Nicolas Goaziou <email@example.com> writes:
>>> So I would keep them. The documentation explicitly states which backend
>>> these keywords are supported by.
>> OK. Then DESCRIPTION and KEYWORD stay in "ox.el", and documented in
>> "Export settings". You need to revert your patch about it.
> I thought we were just discussing criteria for being at a particular spot
> in the manual, not in the code.
As I explained, both are linked:
- Anything defined in "ox.el" is documented in "Export settings" ;
- Anything defined in "ox-backend.el" is documented in "Backend
This is a hard rule. Even if it means repeating documentation in three
different places, some back-end might use differently the same keyword
For the record, if the situation ever rises again, I think that
a keyword can be added to "ox.el" only if
- it is supported at least in every major back-end (ASCII, HTML,
LaTeX, ODT and Texinfo)
- it comes with a toggle in the OPTIONS line e.g. keyword:nil
Even when these criteria are met, this move shouldn't be taken lightly
as it implies all back-ends should try hard to support it.
Again, keywords in this category are to be documented in
(info "(org)Export settings").
> So should I also move the SUBTITLE to ox.el or keep it in files? I think
> it's OK to just define it in the files where it makes sense...
SUBTITLE, DESCRIPTION and KEYWORDS can be defined in the libraries where
they are used. Only the documentation needs to be adapted, per above.
Sorry for the confusion.
>> We will have to take care about support for missing back-ends. E.g.,
>> ASCII could treat DESCRIPTION as a quote box just below title.
> Would that not be an abstract? I'm not sure I think description should be
> handled like that.
Forget about it. I'm not sure DESCRIPTION should be handled at all in
next prev parent reply other threads:[~2015-03-31 10:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 14:19 [ox, patch] #+SUBTITLE Rasmus
2015-03-27 15:08 ` Andreas Leha
2015-03-27 15:12 ` Rasmus
2015-03-27 15:35 ` Andreas Leha
2015-03-28 15:40 ` Nicolas Goaziou
2015-03-28 15:55 ` Rasmus
2015-03-28 17:15 ` Thomas S. Dye
2015-03-29 9:44 ` Nicolas Goaziou
2015-03-29 11:50 ` Rasmus
2015-03-29 13:05 ` Nicolas Goaziou
2015-03-29 13:13 ` Rasmus
2015-03-30 7:39 ` Nicolas Goaziou
2015-03-30 10:35 ` Rasmus
2015-03-31 10:18 ` Nicolas Goaziou [this message]
2015-03-31 10:35 ` Rasmus
2015-03-31 10:47 ` Nicolas Goaziou
2015-03-31 15:50 ` [org.texi] New keywords tables (was: [ox, patch] #+SUBTITLE) Rasmus
2015-03-31 20:33 ` [org.texi] New keywords tables Nicolas Goaziou
2015-03-31 21:57 ` Rasmus
2015-04-01 11:53 ` Rasmus
2015-04-01 19:37 ` Nicolas Goaziou
2015-04-01 21:55 ` Rasmus
2015-04-01 22:34 ` [ox, patch] #+SUBTITLE Rasmus
2015-04-08 21:25 ` Rasmus
2015-03-29 11:16 ` Rasmus
2015-03-31 10:21 ` Nicolas Goaziou
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).