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

[Gustav Wikström]

Ok, so change pushed...

Where org-element-link-parser now sets one extra property only for attachment 
links. The exporters and org-link-open use this additional information when 
exporting and opening attachment links. Feature parity with file links should 
now be complete. Note that exporters outside of the Org mode repo need to be 
aware of the attachment link type if the path expansion is to be correct. They 
aren't translated in between into file-links. Not doing that translation is the 
proper think in my opinion. No magic hiding of the attachment link type. Who 
knows - maybe some exporters in the future need the link as is, without 
expansion!?. Making an exporter in the wild aware of attachment links can be 
done using org-element-property and the new property :attachment-path created 
by the parser only for attachment links.

Regards
Gustav

> -----Original Message-----
> From: Gustav Wikström
> Sent: den 17 januari 2020 19:36
> To: Nicolas Goaziou <address@hidden>
> Cc: address@hidden
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Hi again,
> 
> > -----Original Message-----
> > From: Gustav Wikström
> > Sent: den 17 januari 2020 15:30
> > To: 'Nicolas Goaziou' <address@hidden>
> > Cc: address@hidden
> > Subject: RE: attachment: link type export to HTML invalid attach dir
> >
> > Hi,
> >
> > [...]
> >
> > >
> > > 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?
> 
> Hmm, I'm actually kind of going full circle here, back to think that the
> logic currently implemented is in its right place... Either that, or to
> just decorate the link in the parse-tree with some auxiliary information
> that can be specific for the type of link. For attachment links that
> auxiliary information would be attachment-path-prefix (or something
> shorter but possibly less clear). For abbreviated links possibly the
> auxiliary information would be it's unexpanded form. But I'm not sure of
> the necessity or need for that, except from allowing interpreters to
> reconstruct the original link.
> 
> >
> > [...]
> >
> 
> Regards
> Gustav