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: Sun, 19 Jan 2020 22:12:20 +0100 Message-ID: <871rrvrw0b.fsf@nicolasgoaziou.fr> References: <87pnfnee7e.fsf@gmail.com> <87o8v6iq7n.fsf@gmail.com> <87tv4xl0z9.fsf@gmail.com> <87blr3v8tm.fsf@nicolasgoaziou.fr> <87eevyud9u.fsf@nicolasgoaziou.fr> <87pnfhrob4.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]:44837) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itHs2-0000d7-Ts for emacs-orgmode@gnu.org; Sun, 19 Jan 2020 16:12:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itHry-0008QV-Ua for emacs-orgmode@gnu.org; Sun, 19 Jan 2020 16:12:34 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:37037) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1itHry-0008P2-LG for emacs-orgmode@gnu.org; Sun, 19 Jan 2020 16:12:30 -0500 In-Reply-To: ("Gustav =?utf-8?Q?Wikstr=C3=B6m=22's?= message of "Sat, 18 Jan 2020 15:14:30 +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: "emacs-orgmode@gnu.org" Hello, Gustav Wikstr=C3=B6m writes: > Functionally it's in a good (and maintainable) state right now, in my > opinion. But I do understand that the contextual attribute added to > the parser may require some discussion. This is not my main gripe here, although I'm not convinced that extra attribute is warranted. My concern is that you hard-code "attachment" type in the parser. I don't think this is the correct way to handle the situation. Some link types specifically handle files, e.g., "docview", yet do not need a special treatment in the parser. Note that "file" links have a good reason to be treated specially there, besides their obvious importance, as their type can be omitted. E.g., [[~/file.org]]. OTOH, I see no strong reason to handle "attachments" in here, since they behave like any other link type. Worse, the parser is more or less the definition of the Org syntax. Therefore, including "attachment" in the parser is a signal meaning that in order to fully implement Org syntax, e.g., in another language, one need to support attachment links. Attachment links are undoubtedly useful, but they are not core, at all. So, I feel uneasy about leaking that type of link in the Element library. Also, you sometimes seem to blur, on purpose, the difference between "attachment" and "file" links. If there should be no difference of treatment between them, as I already suggested, you may want to consider "attachment" as some functional link abbreviation. Then the "attachment" type doesn't really exist, much like the "bugzilla" link type from the manual. In any case, we need a proper definition, a proper category too, for "attachment" links. Meanwhile, modifying the parser is just grasping at straws. > I argue that the attachment folder is a part of the attachment link, > even though the information is found at a different location in the > document (i.e. as a property to nodes in the document hierarchy). > Parsing an attachment link would then be incomplete if that > information is discarded. I argue that the buffer position of the attachment link and the path as written in the link are enough to fully expand the attachment file name. If I'm wrong, which could be, I probably didn't invest enough time in the Attach changes, then having the expanded form in :path and the initial form in :raw-path is enough. > One option to adding an attribute could be to modify existing > properties by adding the attachment folder to, for example, the path > property. But that means to remove information about what was written > as path in the original link. There is :raw-path for that purpose. > So I argue to keep path as the original path. But that means extra > information is needed to also make it work in the filesystem. If we > would translate an attachment link to a file link in ox.el that means > we remove the option for exporters to decide for themselves what to do > with the link. And I think the exporter should have that option. :) Let's first think about what category of object an attachment link belongs to. Then we can discuss about how to export it.=20 Again, if "attachment" =3D=3D "file", the exporters shouldn't treat them differently. If "attachment" is a new link type, it should define its own rules in its own library, namely "org-attach.el". > Right now the ASCII exporter for example outputs attachment links as > attachment:expanded_path instead of file:expanded_path. Since the link > type actually is attachment. And for a solemnly textual export the > exported information should be kept as close to source as possible. So > either we explicitly and always say attachment-links *are* file-links > in disguise (i.e. even change type in the parser), or we don't say > that, and then don't say that all the way to the edge of the system. > And let the uses of the link type decide themselves what to do. Which > is what I propose. As I explained above, your proposal is not crystal clear. My gut feeling is that "attachment" links are just a regular link type, that can be opened, and exported, like "file" links. They should live in "org-attach.el", using the provided tools to define new link types, like almost every other link types do. If those tools are not enough to express all the subtleties of "attachment" links, then let's spot the needs and improve those tools. That will benefit to every developer that wants to implement a new link type, what creating another corner case in the parser cannot do. Regards, --=20 Nicolas Goaziou