From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: attachment: link type export to HTML invalid attach dir Date: Fri, 14 Feb 2020 01:16:10 +0100 Message-ID: <87imkat451.fsf@nicolasgoaziou.fr> References: <87eevyud9u.fsf@nicolasgoaziou.fr> <87pnfhrob4.fsf@nicolasgoaziou.fr> <871rrvrw0b.fsf@nicolasgoaziou.fr> <87muairkam.fsf@nicolasgoaziou.fr> <87y2th0yc7.fsf@nicolasgoaziou.fr> <878sle1ng9.fsf@nicolasgoaziou.fr> <875zgausnb.fsf@nicolasgoaziou.fr> <87o8u2tbhg.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:43995) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2Oeb-0001yw-9d for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 19:16:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2OeZ-0001j5-NP for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 19:16:20 -0500 In-Reply-To: ("Gustav =?utf-8?Q?Wikstr=C3=B6m=22's?= message of "Thu, 13 Feb 2020 22:07:41 +0000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Gustav =?utf-8?Q?Wikstr=C3=B6m?= Cc: Bastien Guerry , "emacs-orgmode@gnu.org" Gustav Wikstr=C3=B6m writes: > What makes attachment links not be a core link type?=20 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 =3D those inside Org mode. > Not core =3D 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! > 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. > 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.=20 We're not. The way it is implemented is not correct. 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". 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. > 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.