RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Hi,

> -----Original Message-----
> From: Nicolas Goaziou <address@hidden>
> Sent: den 17 januari 2020 01:40
> To: Gustav Wikström <address@hidden>
> Cc: address@hidden
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström <address@hidden> 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.

Hmm, interesting... And are we sure the destructive behavior is something we 
want to maintain? I for one would vote for the parsers ability to provide 
information that can reconstruct the source... Is it really worth the space 
saving in the parse tree to do that destruction? I feel inclined here to add a 
:link and :raw-path property to the output from the link parser for example. 
That would allow those links that expand to be stored in the parse tree in both 
expanded and non-expanded form. 

Reasons against?  

> 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.

Yes, this is a reason against... But big enough? I humbly question that a bit. 
Also, would it be feasible to store the original "raw" form only if it differs 
from the expanded form? It may complicate the interpreters work though... They 
would have to have a bit more insight into when the original form will be 
needed. Not sure of the better design decision here. 

> 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.

It's actually not only specific to exporting. Opening attachment links show a 
similar issue (org-link-open). Because the current way to open files and 
attachments differ. And it shouldn't have to! That as well would be solved if 
the link parser would take care of the path expansion. One example of the 
difference today is that attachment links cannot abide to any prefix argument. 
As a user I would expect the prefix arguments that work for files to also work 
for attachments. Something I think we can fix here, by making the parser do a 
little bit more work. I'd be happy to apply a patch. 

Kind regards
Gustav