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

[Gustav Wikström]

Hi,

> -----Original Message-----
> From: Nicolas Goaziou <address@hidden>
> Sent: den 18 januari 2020 12:34
> To: Gustav Wikström <address@hidden>
> Cc: address@hidden
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Hello,
> 
> Gustav Wikström <address@hidden> writes:
> 
> > Ok, so change pushed...
> 
> I'm sorry, but this is going too fast. We're discussing core design here
> (the parser), and I couldn't even answer your proposal. Let's at least
> reach an agreement on the change to make.

Yes, agreed, it was a bit fast. The final changes was done to not stop "in the 
middle" so to say, with something both you and me think is suboptimal. 
Functionally it's in a good (and maintainable) state right now, in my opinion. 
But I do understand that the contextual attribute added to the parser may 
require some discussion. If the decision is to not allow contextual attributes 
in the parser I'm prepared to revert and change again. No stress though.

Just to add a note about the trail of my thoughts regarding this... And why I 
thought the contextual attribute was a good option here:

I argue that the attachment folder is a part of the attachment link, even 
though the information is found at a different location in the document (i.e. 
as a property to nodes in the document hierarchy). Parsing an attachment link 
would then be incomplete if that information is discarded. One option to adding 
an attribute could be to modify existing properties by adding the attachment 
folder to, for example, the path property. But that means to remove information 
about what was written as path in the original link. So I argue to keep path as 
the original path. But that means extra information is needed to also make it 
work in the filesystem. If we would translate an attachment link to a file link 
in ox.el that means we remove the option for exporters to decide for themselves 
what to do with the link. And I think the exporter should have that option. :) 
Right now the ASCII exporter for example outputs attachment links as 
attachment:expanded_path instead of file:expanded_path. Since the link type 
actually is attachment. And for a solemnly textual export the exported 
information should be kept as close to source as possible. So either we 
explicitly and always say attachment-links *are* file-links in disguise (i.e. 
even change type in the parser), or we don't say that, and then don't say that 
all the way to the edge of the system. And let the uses of the link type decide 
themselves what to do. Which is what I propose. But with the addition of a bit 
of extra information contextual for the attachment links. 
 
Whoops long paragraph, sorry... I'm just trying to explain my current way of 
looking at this.

Regards
Gustav