Gustav Wikström <> writes:

> Hardcoding the translation of attachment-links into file-links in an
> in-between layer (ox.el - that is somewhat complicated as well) is not
> transparent and I think best to avoid. Even if an attachment link is
> /very/ similar to a file link it may be best still to treat them for
> what they are. If some export back-ends out in the wild don't work
> with attachment-links today then so be it. But let's at least make it
> easy to fix! So I'll try to remove the hard coding of org-attach
> invocation and instead make the attachment-path when parsed by
> org-element return a path that is an actual file-system path out of
> the box. I'll see what I figure out in terms of code I suppose...!
> What do you say?

It is true that Element library expands link abbreviations right before
parsing a link, and an attachment is similar to a local link
abbreviation. This is not great because some information is lost in the
process: interpreting the parse tree will not bring the abbreviation
back, only its expanded form. Actually, `org-link-expand-abbrev' is
called so that the parser knows what is the true type of the link, since
abbreviations could expand to anything. OTOH, attachments can only
expand to a "file" link, so the motivation for expansion doesn't hold.

Besides, there's no good reason to store redundant, or even remote,
information in the parse tree. The parser needs to be as low level as

Moreover, the issue encountered here is specific to export, so it makes
sense to solve at the export level, i.e., in "ox.el". This is not
trivial though, as it needs to be done very early, much link footnotes.
Indeed, since the meaning of the link is position dependent, including
parts of a document, or executing arbitrary code can mess it up. IOW
expansion should happen in `org-export--prepare-file-contents', i.e.,
within every included piece of text, and in `org-export-as', somewhere
after `org-export-expand-include-keyword' call, but before Babel code



Reply via email to