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

[Gustav Wikström]

Continuation from previous answer,

> -----Original Message-----
> From: Nicolas Goaziou <address@hidden>
> Sent: den 13 februari 2020 21:41
> To: Gustav Wikström <address@hidden>
> Cc: address@hidden; Bastien Guerry <address@hidden>
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> [...]
> 
> > Given the above paragraph, the :path and :search-option property
> > doesn't make sense in the parser. :raw-link is enough. Less ambiguous
> > names for :path and :search-option would be :file-path
> > and :file-search-option. But that's sub-typing. We've already
> > concluded that that should not belong to the parser.
> 
> I don't have much time, I apologize if I'm not clear.
> 
> I disagree with you conclusion. Sub-typing is necessary in the parser.
> The `link' object is complex, so it needs categories or types. There are
> plain links, angle links, square links. In this last category, there are
> internal links, which include coderefs, fuzzy links, custom id, file
> links, and, "links with an explicit scheme part". For each of these
> categories, it is fine to have specific properties, like search-options.

Sure, that's not too far away from what I suggested in one of my first mails on 
the subject (except I took it a few steps too far maybe). Saying there are 
properties for categories of sub-types is fine but then this needs to be made 
much more explicit than today. 

> Note that this is sub-typing per syntax, not by meaning. This is what
> should not move, unless absolutely necessary. For example, attachment
> links belong to "square links with an explicit 'attachment' scheme
> part". That is all the parser needs to know.

That, and the way to extract the :search-options and :application from the 
link, as is done for file-links. Since attachment links would fit into your 
category of links that needs specific properties, like search-options.

> Now, it is true that [[file:...]] links are put in the same category as
> [[~/...]] links, for practical reasons, i.e., you wouldn't want them to
> differ in meaning. But this is a breach in the categories above.

Perfectly valid in my opinion. [[~/...]] is shorthand for [[file:~/...]] and, 
as long as documented as such, I see no breach. Only one such shorthand is 
possible anyways so not much ambiguity there.

> We might ignore the :search-option part in file links, but it's very
> easy to get, and, more importantly, we must extract the filename, so
> further parsing is necessary.

As you might have figured, I don't hold a very strong opinion on which design 
decision to take. I just want the choice to be based on principles and to be 
without ambiguities. If you say there are sub-types of links that require the 
:search-option, then fine, let it be so. But then we have to make it perfectly 
clear which particular types this applies to. And also make it clear that those 
special properties are only available for built-in types. I.e. to use them one 
have to get the new link-type into Org mode and into org-element.el.

> > I agree that option 1 is suboptimal. :search-option isn't obvious as
> > a property for all link types. Since option 3 is fairly trivial,
> > option 2 isn't necessary either. For attachment links to reuse
> > the :search-option semantics, without the hard-coding we're currently
> > doing, I see one option where attachment link higher order functions
> > could reuse file link higher order functions. Those file link higher
> > order functions don't exist yet as far as I know.
> 
> Higher order functions for what? `org-open-file' is such a higher order
> function for opening file links. There is no higher order function for
> exporting because each exporter handles file links differently. A higher
> order function for parsing doesn't mean much, since the consumer is not
> known yet.

Yes, each exporter handles file links differently. And I'm saying each exporter 
shouldn't handle file links at all. They should delegate that to the file 
exporter higher order function. In the same way that other link types are 
supposed to be dealt with. Principles.

> At this point, the best thing to do is to clarify what you need.
> I probably do not understand it.

I'm trying :) But it's not that /I need/ anything. It's rather the issue of how 
to solve the conundrum we're in. Where you say "attachment" links should work 
differently and not be hardcoded next to file links. And I'm saying it won't 
work unless we refactor how file-links are handled. And how we should have a 
principled approach to these kinds of things.

> > It might be seducing but I'm not sold. I'd rather have an
> > attachment-link exporter explicitly reuse functionality for exporting
> > file links than automatic translation. For that to be possible, there
> > first is a need for a file link exporter function.
> 
> I don't see how that would be possible, since it would be different for
> each back-end. Again, do you have a more precise idea about what it
> would do?

It would do exactly the same thing that other link type exporters are supposed 
to do. I.e. implement the translation for each back-end.

Kind regards
Gustav