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

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Gustav Wikström <gustav@whil.se> writes:

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

This is not my main gripe here, although I'm not convinced that extra
attribute is warranted. My concern is that you hard-code "attachment"
type in the parser. I don't think this is the correct way to handle the
situation.

Some link types specifically handle files, e.g., "docview", yet do not
need a special treatment in the parser. Note that "file" links have
a good reason to be treated specially there, besides their obvious
importance, as their type can be omitted. E.g., [[~/file.org]]. OTOH,
I see no strong reason to handle "attachments" in here, since they
behave like any other link type.

Worse, the parser is more or less the definition of the Org syntax.
Therefore, including "attachment" in the parser is a signal meaning that
in order to fully implement Org syntax, e.g., in another language, one
need to support attachment links. Attachment links are undoubtedly
useful, but they are not core, at all. So, I feel uneasy about leaking
that type of link in the Element library.

Also, you sometimes seem to blur, on purpose, the difference between
"attachment" and "file" links. If there should be no difference of
treatment between them, as I already suggested, you may want to consider
"attachment" as some functional link abbreviation. Then the "attachment"
type doesn't really exist, much like the "bugzilla" link type from the
manual.

In any case, we need a proper definition, a proper category too, for
"attachment" links. Meanwhile, modifying the parser is just grasping at
straws.

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

I argue that the buffer position of the attachment link and the path as
written in the link are enough to fully expand the attachment file name.

If I'm wrong, which could be, I probably didn't invest enough time in
the Attach changes, then having the expanded form in :path and the
initial form in :raw-path is enough.

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

There is :raw-path for that purpose.

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

Let's first think about what category of object an attachment link
belongs to. Then we can discuss about how to export it. 

Again, if "attachment" == "file", the exporters shouldn't treat them
differently. If "attachment" is a new link type, it should define its
own rules in its own library, namely "org-attach.el".

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

As I explained above, your proposal is not crystal clear.

My gut feeling is that "attachment" links are just a regular link type,
that can be opened, and exported, like "file" links. They should live in
"org-attach.el", using the provided tools to define new link types, like
almost every other link types do. If those tools are not enough to
express all the subtleties of "attachment" links, then let's spot the
needs and improve those tools. That will benefit to every developer that
wants to implement a new link type, what creating another corner case in
the parser cannot do.


Regards,

-- 
Nicolas Goaziou