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

[Gustav Wikström]

Btw, the change 20d293b4a was done after a filed bug report. Maybe should be 
mentioned as well. The change was not something I just felt like doing just for 
the fun of it.

Regards
G

> -----Original Message-----
> From: Kyle Meyer <address@hidden>
> Sent: den 14 februari 2020 03:42
> To: Gustav Wikström <address@hidden>; Nicolas Goaziou
> <address@hidden>
> Cc: Bastien Guerry <address@hidden>; address@hidden
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström <address@hidden> writes:
> 
> >> Gustav Wikström <address@hidden> writes:
> >>
> >> > Ah, you mean the reference on line 3216. No, I don't think it can
> >> > be removed. And I honestly don't think it should be either. It's
> >> > there to let attachment links mirror the peculiarities of file
> >> > links. It's needed for feature compatibility. I don't see the
> issue with that.
> >> > It's a core link type and it needs the information. That
> particular
> >> > logic doesn't affect the parse tree. It's there only to give
> >> > attachment links the same properties as file links.
> >>
> >> I disagree. This is not a core link type. The issue is that the
> >> parser should self-contained. Please use a different way to obtain
> >> the information; we already discussed it and suggested multiple
> solutions.
> >
> > 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.
> 
> It seems unfair to say you can't remove it because it would break
> functionality.  You committed 20d293b4a (Give link parser knowledge of
> attachment link expanded path, 2020-01-18) without posting it to the
> list [0] and giving Nicolas a chance to comment, which you've agreed
> was too hasty [1].  Misjudging the situation is of course okay, but
> please don't use that as a reason to keep a change that would not have
> landed if you had submitted it for discussion.
> 
> [0]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00155.html
> [1]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00162.html