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

["Gustav Wikström" <gustav@whil.se>]

Hi again,

> -----Original Message-----
> From: Gustav Wikström
> Sent: den 16 januari 2020 22:42
> To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Cc: numbchild@gmail.com; emacs-orgmode@gnu.org
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Hi Nicolas,
> 
> > -----Original Message-----
> > From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> > Sent: den 16 januari 2020 14:18
> > To: Gustav Wikström <gustav@whil.se>
> > Cc: numbchild@gmail.com; emacs-orgmode@gnu.org
> > Subject: Re: attachment: link type export to HTML invalid attach dir
> >
> > Hello,
> >
> > Gustav Wikström <gustav@whil.se> writes:
> >
> > > Ah yes. Found the culprit for this issue. Hopefully the last one.
> > > The exporter doesn't actually move the point in the buffer during
> > > the export. So org-attach-expand tried to expand from the first
> > > character in the buffer. This should be fixed from a few minutes ago.
> >
> > I'm not sure hard-coding attachment links in exporters in the best way
> > forward. For example, exporters in the wild may not cope with them
> > before a long time, if ever. There is some code duplication, too.
> 
> Yes indeed, duplicated functionality for all export backends as it stands.
> 
> >
> > If attachments links are similar to file links from an export point of
> > view, then I suggest to add a phase in ox.el to expand the former into
> > the latter, before even using export back-ends. This way, there is no
> > change required in the exporters, shipped in or not.
> 
> Yeah, I do think attachment links should be treated as file links when
> exported. And I like this suggestion, although that means I probably have
> to dig into the ox.el code. Not an easy task. I suspect you'd guide me to
> adding logic inside org-export-as for this. I'll have a look starting from
> there. But wouldn't mind some further insights here!

After thinking a while I'm leaning towards thinking this should be handled already in the element link parser and interpreter. Need a bit more metadata for that though, to be able to deconstruct and reconstruct the link properly while still providing the correct paths.

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? 

> 
> Regards
> Gustav
> 
> >
> > Regards,
> >
> > --
> > Nicolas Goaziou