Re: Thoughts on the standardization of Org

[Tim Cross <theophilusx@gmail.com>]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

>
> A more subtle issue, and one that I raised earlier, is the underlying
> infinite customization provided by Emacs.  Some of my macros are elisp
> code.  A standard for the structure of org mode documents could exist
> but using such standard-compliant documents would be shackled by not
> having elisp available to process the macros.  They would really only be
> usable within Emacs and hence my suggestion that what people really
> want, without knowing it, is Emacs everywhere. ;-) [1]
>

I think the above is perhaps the most critical point. Much of the talk
on standardisation seems to be focusing on org's markup layer. This is
only a small part of org. Many of my org documents include macros,
results from code block evaluation and rely on elisp code execution when
certain content changes (such as changing a todo status). Without any of
this, the document is not an accurate representation compared to how it
is when viewed/used within Emacs. Even the goal of collaborative editing
won't work because changing the data outside Emacs won't trigger the
macros, functions, code blocks etc to update dependent parts (e.g.
changing the TODO status won't result in the timestamp I record in the
draw from being updated or updating that value in a table wo't result in
re-calculation on formulas etc).

One suggested benefit for standardisation was in being able to add a
MIME type. Like others have mentioned, I'm unclear on how exactly adding
a mime type really helps anyone. Having a MIME type only gives value if
you can also have a MIME handler. Nobody except Emacs users have a MIME
handler for *.org files and if you are an Emacs user, then Emacs will
handle that type based on the built-in type handlers. Even if you had a
very basic org parser, about all you might get is some syntax
highlighting and maybe some folding support. You are unlikely to have
much editing support (for example, you won't know from just the file
what the defined keywords are, only the keywords used, same with tags,
priorities, etc).

People have mentioned that github and other systems support org mode
files. I think this is a little misleading - they support a subset of
the org-mode markup and can add minimal text highlighting based on that
markup. These implementations all seem only partially complete and tend
to only handle highlighting for more common languages. While it is great
they have this support, to view this as proof of a the viability of an
external non-Emacs org-mode is perhaps a little optimistic.

The term 'standardisation' might have been a little misleading for this
discussion. Much of what people seem to be talking about could be
satisfied with a completed syntax reference like the one on worg. This
would be sufficient to allow development of systems that are able to
parse an org file and render it in specific formats (like github does).
Perhaps focusing on how to make this document as clear and complete as
possible would be a better effort than trying to define some formal
specification of the whole org-mode system.