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

[Nicolas Goaziou]

Gustav Wikström <address@hidden> writes:

> What makes attachment links not be a core link type? 

1. Org Attach is not loaded by default
2. Implementing Org syntax doesn't require to implement attachments

Attachment links are in the same category as Docview links, for example.
There is no "docview" occurrence in "org-element.el". We have been there
already.

> As I see it we have two categories here: Core = those inside Org mode.
> Not core = those in external libraries. No other distinction needs to
> be made. If a link type is inside Org mode, let it then use the
> special properties that Org mode provides.

Sure thing, but you use the wrong ones!

> Attachment links need to be treated just as file links in most
> regards. Since file-links have special logic which attachment links
> also needs. Thus a reference to attachment in org-element.el. Nothing
> strange here, nothing breaking and the parser is still self-contained.

Attachement links should live only in "org-attach.el": like 99% of other
links do live in their own library. They do not require a special
treatment.

Again, the parser is not self-contained if it references org-attach.el.

> Maybe time for Bastien to step in. Because I can't remove the
> reference to attachment in org-element.el without breaking it's
> functionality. Which, btw, was broken before adding the reference in
> org-element.el. The thing that started this discussion in the first
> place. We're in a better place now. 

We're not. The way it is implemented is not correct.

For opening link, attachment links should use the :follow link
parameter. The "following" function can extract the search option, if
any, and the file name, then call `org-open-file' appropriately. You're
doing it backwards and modify `org-open-file' instead. Additional links
are not supposed to modify "ol.el".

For exporting link, it should use the :export link parameter. The
"exporting" function can extract the search option, if any, and the file
name. It can then re-create a file link object, and call
`org-export-data' on it. You're also doing it backwards here and prefer
to modify each export back-end instead.

> Attachment links works as intended. It would be a pity to have to
> change that because of your argument that attachment links aren't
> "core" enough to be mentioned in org-element.el.

I strongly insist that it should be removed. I gave you ways to solve
the issue. If you need anything else, let me know, but please consider
implementing them.