emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rasmus
Subject: Re: [O] [ox, patch] Add #+SUBTITLE
Date: Tue, 24 Mar 2015 10:37:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> E.g., when creating a new export back-end, it is quite obvious that one
> will need to handle TITLE, DATE, AUTHOR and EMAIL somehow. Now, if you
> request handlers for SUBTITLE, KEYWORDS and DESCRIPTION, it becomes more
> tedious to achieve the task.

Isn't the point that you don't have to support those (e.g. markddown).
The current documentation is pretty specific about not having expectations
about KEYWORDS and DESCRIPTION working.  It would be the same for
SUBTITLE.

> This is not really about SUBTITLE, but, sooner or later, we will have to
> draw a line between common features ensuring compatibility between
> back-ends and specific ones. The cost of the former is some orders of
> magnitude higher.

This is why I proposed SUBTITLE as a feature of a few backends: ox-ascii,
ox-html, ox-odt, and ox-latex (and some derived backends).

>> Yeah, I still have a patch for that...  I still have to do the
>> documentation changes.
>
> Unless we decide that KEYWORD and DESCRIPTION should move to the "common
> features" discussed above. In this case, they stay in "ox.el" and all
> major back-ends are expected to handle them. WDYT?

I think it is fine either way.  But I have never used DESCRIPTION and I
don't use KEYWORDS regularly.

>>> Now, if SUBTITLE is a feature desperately needed everywhere, which can
>>> be discussed, it should be moved to "ox.el" and probably
>>> `org-element-document-keywords'. IMO, this is not necessary. SUBTITLE
>>> should be kept for back-ends that can handle it.
>>
>> IMO it is.
>
> See above. I don't mind much, as long as we eventually stop
> compatibility hell at some point.

I think I didn't understand the first quote above (prefixed with ">>>").
It should *not* be a common feature.  It should be a feature of the
backend where it makes sense, namely backends for text documents at large.

—Rasmus

-- 
Together we'll stand, divided we'll fall



reply via email to

[Prev in Thread] Current Thread [Next in Thread]