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

["Gustav Wikström" <gustav@whil.se>]

Hi,

> -----Original Message-----
> From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Sent: den 14 februari 2020 01:16
> To: Gustav Wikström <gustav@whil.se>
> Cc: emacs-orgmode@gnu.org; Bastien Guerry <bzg@gnu.org>
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström <gustav@whil.se> 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!

I meant that Core = inside the Org mode repository of source code files. Both Docview and Attachment is, both are mentioned in the manual as part of the system. Both should be able to use :search-option inside the Org element parser.

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

It doesn't referencen org-attach.el any longer. That reference is removed. What remains is a reference to the string "attachment". You may argue that even that is to much. And I can only agree with that vision if you also state that org-element shouldn't reference the string "file" either. Anything else is a subjective design that puts a sentiment on "more" or "less" importance of link types and how to regard if they're "important" enough to be mentioned. I don't think you want that in org-element any more than I do.

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

Functionally we are - we have working attachment links that are treated in the same way as file links through out Org mode. Since there is special treatment for file links in Org, attachment links needs the same special treatment to get the same behavior. You might see it as a regression in the design of org-element.el. To which I've already given arguments about why it's not really - and different ways it can be solved - by removing special file-related properties from org-element.el. The added string-reference to attachment links is there because special string-references to file links are there. If special file link references are removed, then clearly attachment links will/should be removed as well.

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

Sure, that's a principle I can agree to. And have already mentioned that I will try to refactor that part by giving the :follow function the same abilities as org-open-file currently has. But that won't be completed quite yet.

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

Which I've argued about already, saying it will be difficult without having file already being treated the same way. I'm not opposed to doing it that way in the long run. But let it be done for file links first, then attachment links can follow. I don't have the capacity to dig into this on my own.

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

In the end, I don't think I can roll back that change without breaking attachment links. For the reasons I've given below. I'm not trying to strong-arm anything here.

/G