Re: [O] [ox, patch] #+SUBTITLE

[Nicolas Goaziou]

Rasmus <address@hidden> 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,