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

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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

> Ok, noted. To my defense I was thinking more in the terms of subtyping
> then hardcoding. Because we have multiple link types which try to
> share an interface. But the interface isn't perfect for all different
> kinds of links.

Then, I suggest to improve the interface.

> So it doesn't seem too farfetched that some of those link types would
> benefit from additional custom properties, specific for those types.
> =application= and =search-option= for example isn't universally
> applicable to all link types.

As a side note, :application is on its way out, i.e., "file+emacs" stuff
is in "org-compat.el".

Also, IIRC, "docview" links have "go to page" option, and they don't
touch the parser.

> What I'm trying to argue for here is: Maybe it's not that crazy after
> all to allow links to have additional properties in the parser based
> on its type? (While certainly still trying to avoid it if possible!)

If new link types may not function correctly without touching the
parser, how do you create new link types out of Org's core? This is not
modular at all.

> (Off topic) I'm sorry to hear that you think I'm intentionally making
> things fuzzy.

Not at all! My wording is terrible. When I wrote

    Also, you sometimes seem to blur, on purpose, the difference between
    "attachment" and "file" links.

I meant something like:

   It seems to me that your intent is to have "attachment" links
   transparently become "file" links to the user.

Hence my suggestion to use link abbreviations. There's nothing negative
in it.

> One can indeed use the buffer position to derive the part of the path
> that comes from the subtree. But leaving it at that puts more
> requirements on the user of the parsed link in order to use it.

And higher order functions in "org-attach" could take care of it. Note
that expanding a link in the parser means all attachment links are
always expanded, even if they are not used. There's a cost to consider.

Besides, parser focus on the contents of the buffer. I think it is out
of its scope to infer file names for abbreviation links. It's more the
job of the parts consuming the parsed data.

> There is no :raw-path available in the properties for a parsed link.
> If there were we surely wouldn't have this conversation and I'd be
> using that already! :) 

I meant :raw-link, sorry.

> I.e. I like this suggestion. I considered using the :raw-link
> property, but the way it's currently used by the parser (i.e.
> expanding abbreviations) stopped me.

Please take how link abbreviations are handled in the parser out of the
equation. I already stated this is not a good way to handle them. We
should probably expand them in a "temp-link" variable, and parse it,
while keeping original link in :raw-link (barring white spaces fixes).
That would not be perfect either, because we would still be inferring
stuff.

That's another topic, really. Let's just ignore it for now.

> So, we're discussing regarding attachment as either: an abbreviation
> or a proper separate link type? I'm not sure what other options we
> have? I personally can't categorize it as an abbreviation since that
> is handled by a separate piece of code with other specifications. I.e.
> attachment wouldn't fit well inside org-link-abbrev-alist. 

What makes you think it wouldn't fit well?

> Attachments should function in the same way as file links, with search
> options and all. But be limited to the current set of attached files.

This isn't incompatible with the above, AFAICT.

> That's basically the way it was before the patches to fix stardiviners
> issues. Except not functioning well enough. It would require quite
> some code in org-attach to replicate existing file links
> functionality. Mostly code duplication I presume.

I didn't read stardiviner issues. Would you mind summarizing them? Or,
at least could you explain what is not functioning well enough?

Anyhow, you may have missed the "let's spot the needs and improve these
tools" part. If current tools lead to code duplication, we can fix that.

> The raw-path option sounds better to my ears.

Except I was meaning :raw-link :)

> One improvement I can think of (outside of the discussion above) is to
> make it possible to pass the argument to org-link-open along to each
> separate link type specialization.

Isn't that the job of :follow when defining a new link type?

> That one has bugged me for some time now, when I've wanted to force
> opening attachment links in emacs but couldn't.

IMO, forcing users to open stuff in a specific, non-configurable, way is
a bad idea. Why would we know better than them?