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
