Robert Pluim <[email protected]> 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
