Hi, Ihor, sorry for the late reply, Ihor Radchenko writes:
> Having read the available replies in this thread, I am thinking of the > following: > > 1. Instead of explicit prefix and suffix, we can unify extra text around > the exported Org element to a template: > > * headline > :PROPERTIES: > :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}" > :ATTR_BACKEND+: "The %%s instances are replaced by the exported element" > :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " > *this*) > :ATTR_BACKEND+: babel_block_name(exported=*this*) > :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space)," > :ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'" > :END: I really like this approach and I would buy it. On the one hand, if I understand correctly, it's a universal solution that doesn't depend on a particular backend (although, to be honest, I don't see much use for this beyond LaTeX: maybe in HTML). And, on the other hand, `:export_template' is an attribute that can be, as you say, very versatile. With this, in my opinion, it would no longer be necessary to define two 'pre' and 'post' attributes. I imagine the value of ATTR_BACKEND (would quotes be necessary?) could be easily converted to a plist, with code borrowed from `org-export-read-attribute': (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} ... etc. ...") > #+ATTR_BACKEND: :export_template "can also work on non-headings" > Paragraph. In this case I would not see it necessary, IMHO. For simple things (of the begin/end style) there are the special blocks. And for more complex pre- and/or post- code we have export blocks and export snippets. Since there is no heading involved here, there would be no danger of the pre-code leaving with the content of the previous header. Best regards, Juan Manuel -- -- ------------------------------------------------------ Juan Manuel Macías https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com