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

[Nicolas Goaziou]

Hello,

Gustav Wikström <address@hidden> writes:

> Unless search-option applies as a general construct for all link types
> I don't think it should be in the parser. Given the discussion we've
> had about design of the parser from before. I.e. if the parser isn't
> supposed to know anything about the specific types themselves, all
> properties of the parsed elements have to make sense for all types of
> links. So either search-option remains but is parsed in exactly the
> same way for all link types, or it's not there at all. And if it's not
> available in the parser, the file link interpreters (that still might
> need to be constructed) gets to parse the :search-option from the
> raw-link as it wishes itself.
>
> 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.

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.

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.

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.

> 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.

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

> True that. There is a balance to strike. Maybe it's time to pull in
> the org element document into the manual? I vote for that at least.

I have no strong opinion on that. It may fit into an appendix, indeed,
or even as a section in first appendix: "Hacking", e.g. "Using the
Parser API".

> Ok, sure. Let the syntax be as rigid as possible, and let
> extensibility to that be dealt with in auxiliary parsing/interpreting
> functions. I guess that would be the approach, put in different words.
> Still correct?

It seems correct.

> 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?

> And the current implementation (since the patch) is good enough imo,
> for now, and until anyone of us does some file link refactoring.

There is an "attachement" reference left in "org-element.el" at the
moment. Can it be removed safely?

I'm Cc'ing Bastien because that particular point should be solved before
any release, IMO.

Regards,

-- 
Nicolas Goaziou