From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Formal description of Org files Date: Mon, 18 Jul 2011 13:04:53 +0200 Message-ID: <87vcuzhmsq.fsf@gmail.com> References: <4213EBED-2EFC-413F-8618-2A594AECEDCF@gmail.com> <877hav8lup.fsf@gmail.com> <2970.1302892280@alphaville.americas.hpqcorp.net> <20110420123741.GA21304@buga.lan> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QildF-0001QC-3j for emacs-orgmode@gnu.org; Mon, 18 Jul 2011 07:05:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QildD-0002LG-KW for emacs-orgmode@gnu.org; Mon, 18 Jul 2011 07:05:00 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:57680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QildD-0002Kt-AL for emacs-orgmode@gnu.org; Mon, 18 Jul 2011 07:04:59 -0400 Received: by ewy9 with SMTP id 9so1580688ewy.0 for ; Mon, 18 Jul 2011 04:04:57 -0700 (PDT) In-Reply-To: (Marcelo de Moraes Serpa's message of "Fri, 15 Jul 2011 13:07:25 -0500") 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: Marcelo de Moraes Serpa Cc: Nick Dokos , emacs-orgmode mailing list , Carsten Dominik Hello, Marcelo de Moraes Serpa writes: > I'm creating a web app that interacts with orgmode files and allows you to > edit orgmode files on the browser. The edit part is not done. I'm quite good > at Javascript, and I wouldn't mind hacking something akin to orgmode elisp > code and this will be what I'll do if everything else fails, but wouldn't > using a grammar be a cleaner and more elegant solution? I didn't follow closely the thread, but I think having a formal description of Org files is unrealistic at the moment. Org "format" is heavily dependant on user-configurable variables deeply installed within emacs. Some of these variables can drastically change the grammar of the Org file. Example: #+begin_src org - item 1 - item a #+end_src Now, if org-empty-line-terminates-plain-lists is a non-nil value, any parser should detect two lists of one item each, while keeping it to nil will imply there is one list of two items. Another example: (setq org-deadline-string "ZORGLUB:"). I let you imagine what confusion it might introduce if the external tool you want to use/implement isn't aware of this change. Sure, it's all plain text, so Org files are accessible from outside emacs. But, for now, only the plain-text structure is accessible from the wild, not the Org one. I can see three options here: - We remove every configurability concerning Org structure: we enforce DEADLINE to stay DEADLINE, lists items to be separated by a blank line, etc. But this isn't serious, is it? - We consider that Org "format" is a package containing the body _and_ every configuration variable. But it isn't plain-text nor a format anymore. - We implement an intermediary real format (maybe in plain text, but I'd favor a nested-lists construct) that would serve as the common denominator for every exporter _and_ importer out there. I already suggested something like this in a recent thread about exporters. Obviously, I think this one is the only viable (and, icing on the cake, this would also be very useful for Org development). Regards, -- Nicolas Goaziou