Gustav Wikström <gus...@whil.se> 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 possible. 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 execution. HTH, Regards,