Robert Pluim <rpl...@gmail.com> writes: > Ihor> However, we have special blocks for this purpose. They are > extendable, > Ihor> as I descibed above. Though some improvements in Org core might be > Ihor> needed if we have to use this extensibility more frequently. > > My first thought here was Org macros, but as far as I can tell they canʼt > be multi-line, which would make them a bit cumbersome to use. Tell us > more about special blocks, the documentation on them is a bit sparse.
Macros are meant to configure per-document level of export. Not global, usually. Special blocks are Org blocks with the following syntax: #+begin_environment [optional parameters] #+end_environment With "environment" being any word except "center", "quote", "comment", "example", "export", "src", and "verse". Currently, latex export directly translates such blocks into \begin{environment} \end{environment} plain text export supports special handling of environment=justifyleft, justifyright. html export supports '("article" "aside" "audio" "canvas" "details" "figcaption" "figure" "footer" "header" "menu" "meter" "nav" "output" "progress" "section" "summary" "video") special blocks texinfo export translates special blocks into @environment [options] @end odt exprot supports "annotation" and "textbox" blocks. etc. Because "environment" can be pretty much anything, we can have a pre-processor in org-export-filter-parse-tree-functions that transforms different special blocks into appropriate form for a given export backend (texinfo, latex, ascii, html, etc). This way, we will not have to rely on backend-specific handling. Such pre-processor currently does not exist, but it would be fairly trivial to implement. We may even introduce an interface similar to org-link-set-parameters for easier configuration of various types of special blocks. WDYT? Best, Ihor