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

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

Hi,

> -----Original Message-----
> From: Kyle Meyer <kyle@kyleam.com>
> Sent: den 14 februari 2020 03:42
> To: Gustav Wikström <gustav@whil.se>; Nicolas Goaziou
> <mail@nicolasgoaziou.fr>
> Cc: Bastien Guerry <bzg@gnu.org>; emacs-orgmode@gnu.org
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström <gustav@whil.se> writes:
> 
> >> Gustav Wikström <gustav@whil.se> 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

Just a short note before leaving for work. I'm not trying to strong-arm anything here. I'm just saying I don't think it's possible to remove the reference without breaking functionality. The changes discussed in [0] and [1] are in my opinion removed already. The reference to attachment we're talking about here is something else. This string reference is not a change in the design of org-element.el for links. The other was. And that's rolled back.

I'm sorry if this is perceived as disingenuous and being done with a bad agenda. It's not. It's a discussion about design. Yes, we disagree about some things. Nothing strange there. Let's talk it out and try to find the middle ground. Which is what's going on. I'll respect the direction given by the better Org moders out there. But in this case I'm simply stating that the principles that needs to apply according to Nicolas will either break attachment link functionality (it was broken before my change in 20d293b4a) or require quite some thinking and/or code duplication in org-attach.el to get it right. And I don't have the capacity for that redesign. Rolling back the change to a broken state is ofc. still possible, but that is more of a regression in my mind than the string-reference to attachment link types in org-element.el.

Which is why I think it's a decision for the maintainer of the project to step in and say if it's fine to have broken attachment links, or if it's fine to let attachment be used the way it is on line 3216 in org-element.el, while there is hard-coded logic for file links the way it is on that line today.

Regards
Gustav