On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
<arne_...@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_...@web.de> wrote:
>
>
> Asa Zeren <asaize...@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
