Ihor Radchenko <yanta...@posteo.net> writes:
> 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.
Ah! Kind of what I thought, but this is more precise explanation than I
could come up with.
>> 2. I assume 'backends' is a list I must create, correct?
>
> That's simply parsing #+attr_all: :export ... value.
Oh! I'm going to have to walk that pcase more carefully.
>> 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).
Makes sense.
Thanks for the explanation.
--
David Masterson
