Hi again, > -----Original Message----- > From: Gustav Wikström > Sent: den 16 januari 2020 22:42 > To: Nicolas Goaziou <m...@nicolasgoaziou.fr> > Cc: numbch...@gmail.com; email@example.com > Subject: RE: attachment: link type export to HTML invalid attach dir > > Hi Nicolas, > > > -----Original Message----- > > From: Nicolas Goaziou <m...@nicolasgoaziou.fr> > > Sent: den 16 januari 2020 14:18 > > To: Gustav Wikström <gus...@whil.se> > > Cc: numbch...@gmail.com; firstname.lastname@example.org > > Subject: Re: attachment: link type export to HTML invalid attach dir > > > > Hello, > > > > Gustav Wikström <gus...@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