Re: Thoughts on the standardization of Org

[Asa Zeren <asaizeren@gmail.com>]

I have collected below some quotations to try to represent the general
sentiments expressed so far in the conversation, upon which I would like to
express some thoughts. Most of these have been repeated several times in spirit,
so they are not just the opinions of the listed authors.

Daniele Nicolodi <daniele@grinta.net> said:
> I don't think it is reasonable to expect much of org-mode being implemented in
> another environment, because that quickly becomes a task as complex as
> implementing Emacs. For example, Org has org-tables, and the formula syntax
> allows for Emacs Calc expressions or Elisp functions to be called: should an
> hypothetical implementation of Org allow the same formulas to be executed?
> Wouldn't that mean that this implementation needs to re-implement a good
> fraction of Emacs (or use Emacs itself for interpreting the formulas?
>
> Maybe the standardization should cover only the "static" parts of Org (IE no
> table formulas, no babel, no agenda, no exporters, etc). However, in this
> case, what is left is little more of a markup language with an editor that
> allows sections folding. You can have this on top of pretty much any markup
> language using Emacs' outline-minor-mode.

Daniele Nicolodi <daniele@grinta.net> said:
> one of the advantages of Org is that, being implemented in Emacs, it has
> infinite potential for customization, thus we would need to agree about what
> org mode is before standardizing it: my Org is not your org, and, thank to the
> features offered be the Emacs environment, I use different flavors of Org in
> different buffers.

I 100% agree that much of the power of org mode comes from the infinite
customization. However, I do not agree that this fact makes standardization
impossible (see below). Additionally, Emacs is not the only customizable tool,
though it is a very good one. The org standard would have to be flexible to
accommodate that "my org is not your org," but this is not impossible.

Ken Mankoff <mankoff@gmail.com> said:
> Therefore, if other tools have the ability to do *something* with an Org file
> (display most of it well enough, allow editing without breaking things, maybe
> implementing a simple Babel interpreter for a few popular languages,
> whatever), this would be A Good Thing.

TEC <tecosaur@gmail.com> said:
> I also think it's to our benefit that non-Emacsers become more comfortable
> with seeing an org file --- as I see it that improves our chances that we can
> directly share Org files with them, which they might be comfortable editing
> and sending back for example, or that a generic tool might think to support
> Org files.

These points are especially important, and while a standard is not the only way
to progress these goals, it is a good step. Also, re the MIME type discussion,
while there was a long list of steps that need to occur for a MIME registration
to be useful, I would like to point out that a standard is the first step
towards that goal, and even though there are more steps, many of them difficult,
that does not mean that we should not make progress.

Greg Minshall <minshall@umich.edu>
> perhaps the standard for e-mail headers (originally, RFC822) might be a useful
> way of thinking about this issue.  it standardizes what it standardizes, and
> then says, "and, by the way, you can put in almost anything else [X-Mailer,
> ...], but you can't count on any other node understanding it".  over time, new
> things are standardized (and, so, moved to, e.g., Mailer, and other things
> aren't.
>
> it seems to me this has worked fairly well, and partly this works because of
> the late Jon Postel's admonition for designing internet protocols: be
> conservative in what you send, and liberal in what you accept.

This is a good precedent for how I would like to standardize org. First,
standardize general structure, without the specifics. Then, as ideas around a
particular feature stabilize, they can be separately standardized, and
incrementally adopted. (Though likely many major implementations (aka Emacs)
would have already implemented it, even though it is non standard.)

For more details on how I think this should be accomplished, see my original
post, and also this reply for clarification:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00009.html

Ken Mankoff <mankoff@gmail.com> said:
> The conversation should move from "it can't be done" or "it isn't helpful"
> (why so much negativity on this thread?) to
>
> + What parts can be standardized and re-implemented outside of Emacs.
> + How do we define graceful failure for the other parts.
> + How do we support 3rd-party implementation in a way that benefits all of us.

This post I also find especially important. There seem to be the ideas that (a)
an incomplete implementation is not useful and (b) a standard would necessarily
either require another implementation to implement all of Emacs or would
eliminate the customizability of org.

Thanks,
Asa