emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Daniele Nicolodi <daniele@grinta.net>
To: emacs-orgmode@gnu.org
Subject: Re: Thoughts on the standardization of Org
Date: Sun, 1 Nov 2020 20:46:09 +0100	[thread overview]
Message-ID: <b28c05a4-8dd8-fcea-03cc-796f5218ade0@grinta.net> (raw)
In-Reply-To: <20201101161317.GA6609@maokai>

On 01/11/2020 17:13, Russell Adams wrote:
> On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
>> First, I would like to repeat the importance of developing standards
>> for org-mode. If we want to expand the influence of org, tooling must
>> expand beyond Emacs.
> 
> I disagree. There are other open text based formats outside of
> Emacs. That Org is so compelling is because it's tightly integrated
> into an Emacs mode which makes using Org data so easy.

I cannot agree more with this statement and a similar statement (that I
am too lazy to go search to provide correct authorship) that stated that
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.

Reading the thread I have the impression that what wants to be
standardized is the syntax of Org, but that is not very different from
the syntax of other text based markup languages such at
reStructuredText, asciidoc, Markdown, or others. What makes Org stand
out, for some applications, is "org-mode" (as the implementation of Org
in Emacs) and the tools built on top of the syntax.

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.

If this is what you are after, I think a much more interesting goal
(from the point of view of Emacs users and Org developers) would be to
fold back some of the improvements org-mode builds on top of
outline-mode back into outline-mode itself. This would immediately be
beneficial as it would probably make Org simpler and the improvements
could be actually be used by many.

I also think that, if you are in the position to choose a format to use
for collaborative projects, reStructuredText may be a better choice as
the syntax is simple, well defined, and extensible. Although, without
trying I don't know if outline-minor-mode can be made to work with
reST-style sections headers. But, if it does not, it should not be hard
to adjust it (see previous paragraph).

Cheers,
Dan


  reply	other threads:[~2020-11-01 19:47 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01  0:22 Thoughts on the standardization of Org Asa Zeren
2020-11-01  0:40 ` Dr. Arne Babenhauserheide
2020-11-01  3:08   ` Asa Zeren
2020-11-01  4:23     ` Pankaj Jangid
2020-11-01  7:54     ` Tim Cross
2020-11-01  2:28 ` Tim Cross
2020-11-01  3:39   ` Pankaj Jangid
2020-11-02 12:39     ` Eric S Fraga
2020-11-02 14:22       ` Greg Minshall
2020-11-02 14:56         ` Eric S Fraga
2020-11-02 15:23           ` Russell Adams
2020-11-02 15:31             ` TEC
2020-11-02 15:48             ` Eric S Fraga
2020-11-02 16:27               ` Carsten Dominik
2020-11-02 22:05           ` Tim Cross
2020-11-03  3:29           ` Greg Minshall
2020-11-01  5:20 ` Tom Gillespie
2020-11-01 10:25   ` Dr. Arne Babenhauserheide
2020-11-01 10:28     ` TEC
2020-11-01 18:02       ` Jack Kamm
2020-11-01 16:03     ` Asa Zeren
2020-11-01 17:27       ` Dr. Arne Babenhauserheide
2020-11-01 17:29         ` TEC
2020-11-01 18:43         ` Asa Zeren
2020-11-01  6:24 ` TEC
2020-11-01 16:13 ` Russell Adams
2020-11-01 19:46   ` Daniele Nicolodi [this message]
2020-11-01 23:10     ` Dr. Arne Babenhauserheide
2020-11-02  8:37       ` Daniele Nicolodi
2020-11-02  9:02         ` TEC
2020-11-02 11:04           ` Daniele Nicolodi
2020-11-02 13:43             ` TEC
2020-11-07 21:20             ` Jean Louis
2020-11-09 14:04               ` Maxim Nikulin
2020-11-09 15:57                 ` Daniele Nicolodi
2020-11-09 15:59                 ` Jean Louis
2020-11-10 16:19                   ` Maxim Nikulin
2020-11-10 20:22                     ` Jean Louis
2020-11-10 23:08                     ` Tom Gillespie
2020-11-11  0:00                       ` Tim Cross
2020-11-09 21:46                 ` Tim Cross
2020-11-09 22:45                   ` Emails are not safe - " Jean Louis
2020-11-10  4:13                   ` Greg Minshall
2020-11-10  4:49                     ` Tim Cross
2020-11-10  7:12                       ` Greg Minshall
2020-11-10 16:29                     ` Maxim Nikulin
2020-11-10 20:35                       ` Jean Louis
2020-11-10 22:30                         ` Tim Cross
2020-11-11  5:03                           ` Jean Louis
2020-11-11  6:40                             ` Tim Cross
2020-11-27 16:49                             ` Maxim Nikulin
2020-11-27 17:16                               ` Jean Louis
2020-11-11 17:10                         ` Maxim Nikulin
2020-11-11 17:34                           ` Jean Louis
2020-11-12  3:39                             ` Greg Minshall
2020-11-11  3:49                       ` Greg Minshall
2020-11-02  9:53         ` Dr. Arne Babenhauserheide
2020-11-02  1:17 ` Ken Mankoff
2020-11-02  8:12   ` Russell Adams
2020-11-02  9:57     ` Dr. Arne Babenhauserheide
2020-11-03  8:24 ` David Rogers
2020-11-03 12:14   ` Ken Mankoff
2020-11-03 12:27     ` Russell Adams
2020-11-03 13:00     ` Eric S Fraga
2020-11-03 13:31       ` Ken Mankoff
2020-11-03 15:03         ` Eric S Fraga
2020-11-03 20:27           ` TEC
2020-11-03 14:38     ` Devin Prater
2020-11-03 22:03     ` David Rogers
  -- strict thread matches above, loose matches on Subject: below --
2020-11-01 13:34 Gustav Wikström
2020-11-01 18:39 Asa Zeren
2020-11-03 22:30 Asa Zeren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b28c05a4-8dd8-fcea-03cc-796f5218ade0@grinta.net \
    --to=daniele@grinta.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).