From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: [ox, patch] #+SUBTITLE
Date: Sun, 29 Mar 2015 11:44:34 +0200 [thread overview]
Message-ID: <87d23sdtod.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87k2y1qfpi.fsf@gmx.us> (rasmus@gmx.us's message of "Sat, 28 Mar 2015 16:55:37 +0100")
Rasmus <rasmus@gmx.us> writes:
>> Could you elaborate a bit in the comment?
>
> Consider if title is nil. With format-spec I'll get an empty <h1></h1>.
> As I remember, the W3 checker dislike these. I have never used these
> html5 slides, so I don't really know how to fix it.
You probably should add this to the comments in the file.
> 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?
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.
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).
>> Nitpick:
>>
>> (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
(and test
... some very long computation)
is less clear than
(when test
... some very long computation)
However, it doesn't apply in this case.
As I warned, this is all about nitpicking anyway.
Regards,
next prev parent reply other threads:[~2015-03-29 9:43 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 [this message]
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
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
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d23sdtod.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).