Re: [POLL] Naming of "export features"

["Sébastien Miquel" <sebastien.miquel@posteo.eu>]

Hi,

Ihor Radchenko writes:
> What I have in mind is an ability to parametrize the transcoders like
> the following:
> 
> (org-export-define-backend 'html
>   '((paragraph . ((paragraph-is-a-link? figure-transcoder :name figure)
>                   (:unless 'figure paragraph-transcoder))))
>   :transcoder-conditions
>   '((paragraph . ((paragraph-is-a-link? (lambda (paragraph contents info)...))))))
> 
> Several ideas in the above:
> 1. Name features as "transcoder conditions"
> 2. The transcoder conditions are now linked to specific Org AST element.
>     They may not only be matched against the whole parse tree + whole raw
>     Org text, but also against the specific branch of AST + chunk of raw
>     Org text corresponding to the branch + the actual exported contents
>     of the AST children.
> 3. "feature implementations" are no longer needed. Instead, export
>     transcoders can contain the implementation lists inline. Each
>     implementation is selected not only depending on the presence of the
>     "feature"/transcoder condition, but also depending on multiple
>     features or arbitrary lisp expression results.
> 4. :when/:prevents apply to specific (possibly named) implementations.
>     This makes more sense than matching against feature.
>     For example, presence of svg images in latex export may or may not
>     mean that \usepackage{svg} is being used, depending on svg
>     implementation. We want to match against \usepackage{svg}
>     specifically rather than only against the presence of svg images.

What benefits does that bring over making enabled features available in 
=info= for the usual transcoders and advising them ?

Your initial example of adding a comment to the end and beginning of the 
document can be done by advising, say, =org-latex-template= and 
concatenating some strings with its =content= argument.

-- 
Sébastien Miquel