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 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 \ --subject='Re: [ox, patch] #+SUBTITLE' \ /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
Code repositories for project(s) associated with this 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).