[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gustav Wikström
Subject: RE: attachment: link type export to HTML invalid attach dir
Date: Thu, 16 Jan 2020 23:07:11 +0000

Hi again,

> -----Original Message-----
> From: Gustav Wikström
> Sent: den 16 januari 2020 22:42
> To: Nicolas Goaziou <address@hidden>
> Cc: address@hidden; address@hidden
> Subject: RE: attachment: link type export to HTML invalid attach dir
> Hi Nicolas,
> > -----Original Message-----
> > From: Nicolas Goaziou <address@hidden>
> > Sent: den 16 januari 2020 14:18
> > To: Gustav Wikström <address@hidden>
> > Cc: address@hidden; address@hidden
> > Subject: Re: attachment: link type export to HTML invalid attach dir
> >
> > Hello,
> >
> > Gustav Wikström <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]