Hi, > -----Original Message----- > From: Nicolas Goaziou <m...@nicolasgoaziou.fr> > Sent: den 18 januari 2020 12:34 > To: Gustav Wikström <gus...@whil.se> > Cc: emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > Hello, > > Gustav Wikström <gus...@whil.se> 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
