David Masterson <dsmaster...@icloud.com> writes:
> Interesting. My elisp is not strong, so a few questions:
>
> 1. Are you saying attr_all does not exist in Org and this code is
> creating it?
Anything in the form of #+attr_<foo> is treated by Org mode as
affiliated keyword. This keyword is stored alongside the following
paragraph/drawer/block/etc in the syntax tree passed to the exporter.
Export backend can then access it as needed. By convention, the backends
make use of #+attr_<backend name> keywords (#+attr_html, #+attr_latex,
etc) and ignore other. But nothing is technically stopping you from
examining values of arbitrary #+attr_<foo> keywords during
export. That's what I did in this code.
> 2. I assume 'backends' is a list I must create, correct?
That's simply parsing #+attr_all: :export ... value.
With my filter, you can write
#+attr_all: :export (ascii html latex)
Paragraph to be exported only to ascii, html, and latex backends.
Or
#+attr_all: :export (not ascii html)
Paragraph _not_ to be exported to ascii and html and to be exported for
all other export backends.
> 3. What does the last argument ('t') to org-element-map do?
> 4. Doesn't org-element-map return data, so isn't the last data
> unnecessary?
The filter should return the modified syntax tree, while
`org-element-map' returns a flattened list. So, we cannot use its return
value. Instead, `org-element-extract' calls modify the tree by side
effect and the whole filter later returns the modified tree (the last
line in the function).
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
