emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Asa Zeren <asaizeren@gmail.com>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Thoughts on the standardization of Org
Date: Sat, 31 Oct 2020 23:08:56 -0400	[thread overview]
Message-ID: <CANKzsSB-8ZdKHomFeXHT8LBJftz4K27uOk64+XGHwZJEPkbzqw@mail.gmail.com> (raw)
In-Reply-To: <87361tgb96.fsf@web.de>

On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
<arne_bab@web.de> wrote:
> The most important point I see here is to avoid hindering the
> development of org-mode within Emacs.

While I definitely support enabling the further development of org-mode, and not
restricting it via a standard, I do see some problems.

> So the most important part of the standard would be areas it doesn’t
> standardize: Reserved for future use in org-mode.

The issue with this is that by picking what areas to reserve, one has
effectively limited the syntactic space that new features can use. This is not a
problem in and of itself, but does make the notion of leaving arbitrary syntax
space reserved impossible, particularly, since in org-mode and similar markup
languages, unadorned text is part of the content, rather than being ill formed,
as in programming languages. This also does not mean that tools can interpret
part of what org-mode considers content as having some domain or implementation
specific meaning. For example, latex blocks. In my opinion, the translation of
these are a language extension by the org-export tool. Even within parts of the
Emacs org implementation, latex blocks should not be considered part of the org
language. For example, the line "* Headline?" in the example below is still
identified as a headline, even though, if the area inside the \begin and \end
commands were supposed to be latex, not org, it should not be.

#+begin_example org
\begin{equation}
* Headline?
\end{equation}
#+end_example

> The most important point I see here is to avoid hindering the development of
> org-mode within Emacs.

> These would then be sections that external tools must handle as
> opaque text so their processing does not break usage within
> org-mode.

In these concerns I see one major flaw. The way they are worded at present
implies that the Emacs implementation of org is the "one true implementation,"
and that all tools in other environments are auxiliary. I believe that if we
want org to grow, then it needs to become unbound from Emacs. It should become a
universal markup format, which just happens to have had many tools first
implemented for Emacs (even if Emacs still will probably remain the best way to
edit org files).

Best,

Asa

On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
<arne_bab@web.de> wrote:
>
>
> Asa Zeren <asaizeren@gmail.com> writes:
> > I would appreciate thoughts on these ideas about how to develop and
> > org specification.
>
> The most important point I see here is to avoid hindering the
> development of org-mode within Emacs.
>
> So the most important part of the standard would be areas it doesn’t
> standardize: Reserved for future use in org-mode.
>
> These would then be sections that external tools must handle as opaque
> text so their processing does not break usage within org-mode.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken


  reply	other threads:[~2020-11-01  3:09 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 [this message]
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
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=CANKzsSB-8ZdKHomFeXHT8LBJftz4K27uOk64+XGHwZJEPkbzqw@mail.gmail.com \
    --to=asaizeren@gmail.com \
    --cc=arne_bab@web.de \
    --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).