Hello,
Marcelo de Moraes Serpa <celose...@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
