From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Samuel Wales" Subject: extensible syntax Date: Sun, 4 Jan 2009 13:33:23 -0700 Message-ID: <20524da70901041233g105f372fv175a47dc9884fa43@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJZf8-0002FG-13 for emacs-orgmode@gnu.org; Sun, 04 Jan 2009 15:33:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJZf3-00026g-87 for emacs-orgmode@gnu.org; Sun, 04 Jan 2009 15:33:29 -0500 Received: from [199.232.76.173] (port=52409 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJZf3-00026Z-4U for emacs-orgmode@gnu.org; Sun, 04 Jan 2009 15:33:25 -0500 Received: from mail-ew0-f13.google.com ([209.85.219.13]:64590) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJZf2-0007Kc-Ig for emacs-orgmode@gnu.org; Sun, 04 Jan 2009 15:33:24 -0500 Received: by ewy6 with SMTP id 6so7877340ewy.18 for ; Sun, 04 Jan 2009 12:33:23 -0800 (PST) Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org A general idea, which might or might not be useful. There are occasionally questions about syntax, like this: Also, I'm afraid definition matching regexp won't play nicely with text indentation, ... -- Paul Or this: What would be safer? -- Carsten I like the footnote implementation, so this is for future features, not necessarily footnotes. One issue when implementing new syntax (or changing existing syntax or cleaning up code) is parsing risk, which I will define as the risk that the syntax and the regexp or matching code: 1) conflicts with user text 2) conflicts with existing features 3) will be hard to maintain 4) constrains future features by making them conflict syntactically 5) makes you run out of syntax to use in the future 6) will require complicated regexps 7) doesn't readily handle stuff you might want in the future, like being combined with another feature 8) will be hard to quote, escape, comment, *boldify*, etc. 9) doesn't handle nestability, print-readability, pretty-printability, syntax coloring, etc. 10) will be inefficient when called in a loop 11) isn't factored out 12) etc. For example, one of the many reasons for using org-IDs (:)) in the conversation manager (as proposed) is that there are already functions to parse org-IDs, so a new syntax is not necessary and therefore parsing risk is minimized. In case parsing risk is a concern when adding a new feature to org, here is one idea: have a generic syntax that is extensible with keywords. The idea is to have a bracketing syntax with a reserved keyword as the first element that says what you are doing. To use footnotes as an example (this is not a suggestion to change footnote syntax, just an example that can be used for future syntax): You might use something like "here is some text to be footnoted $[fn apple]" to specify the footnote link, and "$[fn-target apples are delicious]" to specify the target. The general point I want to make is that once such a syntax is decided on, many future features are possible without introducing parsing risk. For example, you can implement a new feature as "$[my-new-feature ...]". Then there is no parsing risk, even though you have just added a new feature. For modifications of features, you can use keywords: "$[my-new-feature ... :myparameter ...]". These are easily parsed by standard functions for parsing lists. You can develop ways to boldify, quote, nest, prettily print, etc. this syntax, and those ways will work well with all future features that use it. Of course, the dollar sign and brackets are not the only possibility; it could be percent sign and parentheses, for example. You will not be starting from scratch. Lisp has already worked out many of these issues. I will leave it to those who write massive amounts of org code to decide whether an extensible syntax might be useful to reduce parsing risk for future features. But I thought that I would propose the idea in case it is of interest. -- For personal gain, myalgic encephalomyelitis denialists are knowingly causing further suffering and death by grossly corrupting science. Do you care about the world? http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm