From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: [dev] Implement "ref" link types Date: Sun, 19 Feb 2012 13:48:50 -0700 Message-ID: References: <87vcn2vgq7.fsf@gmail.com> <87linyvbf7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzDgj-0002RW-9h for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 15:48:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzDgh-00062S-SE for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 15:48:53 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:61399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzDgh-00060s-Nh for emacs-orgmode@gnu.org; Sun, 19 Feb 2012 15:48:51 -0500 Received: by iagz16 with SMTP id z16so8570079iag.0 for ; Sun, 19 Feb 2012 12:48:50 -0800 (PST) In-Reply-To: <87linyvbf7.fsf@gmail.com> 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.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Org Mode List On 2012-02-19, Nicolas Goaziou wrote: > Ok, I found the thread[1] about extensible syntax for links. Again this isn't just for links and if your syntax does all you ever anticipate, then I like it. I am talking about the future and the difficulty of adding ad-hoc syntax fore new features /later/. There are a few other threads (just FYI). I might have them listed someplace. Overview (also FYI): one concern is syntax creep in Org for new features. This affects external parsers and overall complexity and nonorthogonality, and introduces parsing risk, in which there are many gotchas -- such as inability to escape, quote, nest, pretty-print, etc. ES/US solves all of that in a single, simple way. If all you're doing is the one set of features now, then your syntax is great. But I'm talking about the future. > I don't think that it would be a good idea to use a completely different > syntax for just one type of link. Either we change the whole link system No, it's not for just one type of link. It applies to new features also, not just for ref links but for ID markers (links to anything, even words, using Org ID), very fancy dates that have features that are too difficult to include in existing date syntax, annotation of words or paragraphs or elements, maybe fancy detangling, browser-like link coloring by expiry and cached links, digraphs, undirected graphs including bidirectional links, super-fancy footnotes, any new feature we do not currently anticipate for the ref syntax or any other feature that would create nonorthogonality and complexity in existing syntax, and many new features we haven't thought of. It won't replace existing syntax. It's for new features. One point is that when we address something (such as nestability) for one new feature, it works for all others automatically. > into the extensible syntax proposal, or we don't change it at > all. I don't mind either way, but that's orthogonal to the problem at > hand. Again I think your syntax is great if that is all it is going to do. All I am doing is raising a possible alternative way of doing it. If you don't like it, that's fine. But my point is that if we only look at the problem at hand, we get syntax creep -- because new features are not at hand. Think of how dates now have to deal with deadlines, repeaters, etc. That's OK, but it's going to get harder to add new features to them. I'm not saying to replace dates, but for many new features, we might want to try something more orthogonal and extensible and universal. >> For example, you might want to put the target anywhere, not just where >> there are elements. > > Org already has targets for that: <> and [[anywhere]]. The Those do not use the Org ID mechanism, so they are brittle and don't operate across files in the same way Org IDs can (IIRC -- do they?). Again it's an example of how the syntax can add features without making parsing difficult. This all concerns future features, not anything today. Just something to consider. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com