Hi again, > -----Original Message----- > From: Gustav Wikström > Sent: den 17 januari 2020 15:30 > To: 'Nicolas Goaziou' <m...@nicolasgoaziou.fr> > Cc: emacs-orgmode@gnu.org > 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
