Re: Formal description of Org files

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Marcelo de Moraes Serpa <celoserpa@gmail.com> 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