[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: attachment: link type export to HTML invalid attach dir
From: |
Gustav Wikström |
Subject: |
RE: attachment: link type export to HTML invalid attach dir |
Date: |
Fri, 14 Feb 2020 07:23:34 +0000 |
Hi,
> -----Original Message-----
> From: Nicolas Goaziou <address@hidden>
> Sent: den 14 februari 2020 01:16
> To: Gustav Wikström <address@hidden>
> Cc: address@hidden; Bastien Guerry <address@hidden>
> Subject: Re: attachment: link type export to HTML invalid attach dir
>
> 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!
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
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/05
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/06
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/07
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/08
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/13
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/13
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/13
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/13
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/13
- RE: attachment: link type export to HTML invalid attach dir,
Gustav Wikström <=
- RE: attachment: link type export to HTML invalid attach dir, Kyle Meyer, 2020/02/13
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/14
- RE: attachment: link type export to HTML invalid attach dir, Gustav Wikström, 2020/02/14
- Re: attachment: link type export to HTML invalid attach dir, Bastien, 2020/02/14
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/14
- Re: attachment: link type export to HTML invalid attach dir, Bastien, 2020/02/14
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/15
- Re: attachment: link type export to HTML invalid attach dir, Kyle Meyer, 2020/02/15
- Re: attachment: link type export to HTML invalid attach dir, Nicolas Goaziou, 2020/02/16
- Re: attachment: link type export to HTML invalid attach dir, Bastien, 2020/02/16