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: Thu, 13 Feb 2020 21:41:28 +0100 Message-ID: <875zgausnb.fsf@nicolasgoaziou.fr> References: <87tv4xl0z9.fsf@gmail.com> <87blr3v8tm.fsf@nicolasgoaziou.fr> <87eevyud9u.fsf@nicolasgoaziou.fr> <87pnfhrob4.fsf@nicolasgoaziou.fr> <871rrvrw0b.fsf@nicolasgoaziou.fr> <87muairkam.fsf@nicolasgoaziou.fr> <87y2th0yc7.fsf@nicolasgoaziou.fr> <878sle1ng9.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]:59040) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2LIo-0001TS-Hr for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 15:41:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2LIm-0003vi-GJ for emacs-orgmode@gnu.org; Thu, 13 Feb 2020 15:41:37 -0500 In-Reply-To: ("Gustav =?utf-8?Q?Wikstr=C3=B6m=22's?= message of "Sat, 8 Feb 2020 15:39:18 +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" Hello, Gustav Wikstr=C3=B6m writes: > Unless search-option applies as a general construct for all link types > I don't think it should be in the parser. Given the discussion we've > had about design of the parser from before. I.e. if the parser isn't > supposed to know anything about the specific types themselves, all > properties of the parsed elements have to make sense for all types of > links. So either search-option remains but is parsed in exactly the > same way for all link types, or it's not there at all. And if it's not > available in the parser, the file link interpreters (that still might > need to be constructed) gets to parse the :search-option from the > raw-link as it wishes itself. > > Given the above paragraph, the :path and :search-option property > doesn't make sense in the parser. :raw-link is enough. Less ambiguous > names for :path and :search-option would be :file-path > and :file-search-option. But that's sub-typing. We've already > concluded that that should not belong to the parser. I don't have much time, I apologize if I'm not clear. I disagree with you conclusion. Sub-typing is necessary in the parser. The `link' object is complex, so it needs categories or types. There are plain links, angle links, square links. In this last category, there are internal links, which include coderefs, fuzzy links, custom id, file links, and, "links with an explicit scheme part". For each of these categories, it is fine to have specific properties, like search-options. Note that this is sub-typing per syntax, not by meaning. This is what should not move, unless absolutely necessary. For example, attachment links belong to "square links with an explicit 'attachment' scheme part". That is all the parser needs to know. Now, it is true that [[file:...]] links are put in the same category as [[~/...]] links, for practical reasons, i.e., you wouldn't want them to differ in meaning. But this is a breach in the categories above. We might ignore the :search-option part in file links, but it's very easy to get, and, more importantly, we must extract the filename, so further parsing is necessary. > I agree that option 1 is suboptimal. :search-option isn't obvious as > a property for all link types. Since option 3 is fairly trivial, > option 2 isn't necessary either. For attachment links to reuse > the :search-option semantics, without the hard-coding we're currently > doing, I see one option where attachment link higher order functions > could reuse file link higher order functions. Those file link higher > order functions don't exist yet as far as I know. Higher order functions for what? `org-open-file' is such a higher order function for opening file links. There is no higher order function for exporting because each exporter handles file links differently. A higher order function for parsing doesn't mean much, since the consumer is not known yet. At this point, the best thing to do is to clarify what you need. I probably do not understand it. > True that. There is a balance to strike. Maybe it's time to pull in > the org element document into the manual? I vote for that at least. I have no strong opinion on that. It may fit into an appendix, indeed, or even as a section in first appendix: "Hacking", e.g. "Using the Parser API". > Ok, sure. Let the syntax be as rigid as possible, and let > extensibility to that be dealt with in auxiliary parsing/interpreting > functions. I guess that would be the approach, put in different words. > Still correct? It seems correct. > It might be seducing but I'm not sold. I'd rather have an > attachment-link exporter explicitly reuse functionality for exporting > file links than automatic translation. For that to be possible, there > first is a need for a file link exporter function. I don't see how that would be possible, since it would be different for each back-end. Again, do you have a more precise idea about what it would do? > And the current implementation (since the patch) is good enough imo, > for now, and until anyone of us does some file link refactoring. There is an "attachement" reference left in "org-element.el" at the moment. Can it be removed safely? I'm Cc'ing Bastien because that particular point should be solved before any release, IMO. Regards, --=20 Nicolas Goaziou