> > 1. Allow for special blocks to take an :options argument.
>
> Although I agree that this would be nice, I imagine the difficulty would be
> that it would be difficult to cater for multiple backends.
It's not really difficult, more on the trivial side. For example, as
an end user I already can install a filter like:
(defun my-special-block-parse-filter (tree backend symbol)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'special-block
(lambda (element)
(save-excursion
(goto-char (org-element-property :begin element))
(when (looking-at "[ \t]*#\\+BEGIN_\\S-+[ \t]+\\(\\S-+\\)")
(let ((options (format ":options [%s]"
(match-string-no-properties 1))))
(org-element-put-property element :attr_latex (list
options)))))))))
And then write:
#+BEGIN_definition Special Block
A block mostly left uninterpreted by core org for the sake of backends
#+END_definition
This is as devoid of boilerplate as possible.
Notice the filter only applies to latex derived backends and won't
take effect if there is an #+ATTR_LATEX clause before the block (this
because it's considered part of the element the regexp won't match
it).
Obviously this can be implemented in a cleaner way by changing
org-latex-special-block in ox-latex.el. Again, the change would be
trivial.
> > 2. Mention the possibility of using special blocks to represent beamer
> > blocks, be it in the manual or in the tutorial.
>
> Given that beamer inherits everything that the LaTeX exporter supports, is
> the special blocks section in the LaTeX exporter documentation not already
> enough?
Not much users seem to be aware of the ablity of using special blocks
for beamer. No example, answer, tutorial out there even mentioned the
possibility. Given its convenience, I would say the beamer export
section should explicitly suggest the alternative.
Best regards
--
Carlos
