emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: gustav@whil.se, emacs-orgmode <emacs-orgmode@gnu.org>,
	David Masterson <dsmasterson92630@outlook.com>
Subject: Re: Concerns about community contributor support
Date: Tue, 20 Apr 2021 01:21:01 -0700	[thread overview]
Message-ID: <CA+G3_PM=HK_L7+8aD7MwjwEDvT7uR0QmS0w-S8NWKnZibm2Mgw@mail.gmail.com> (raw)
In-Reply-To: <87czup6d0u.fsf@gmail.com>

Hi Tim, David, and Gustav,
    I am fairly certain that with only a few exceptions it is possible
to specify a context free grammar for org syntax, followed by a second
pass that deals specifically with markup and a few other forms,
notably the reassembly of things like plain lists. The fact that this
is possible because most org constructs are line oriented.

Just a note that the linked parser.rkt [0] is indeed a BNF describing org
syntax in the same style as a bison/yacc grammar. One of the reasons
why I set out to work on this was precisely so that there could be a
reference that could be consulted by the community when questions
about extended org come up.

There are proposals for new syntax that appear on this list with
terrifying frequency, and they are routinely shot down or simply
ignored for good reason, however it is hard to communicate that to
enthusiastic contributors who have an immediate use case that they
want to solve and share and are unlikely to be aware of side effects.
Having a grammar where such issues can be tested empirically should
provide a significant safeguard while also making it easier for
contributors to play with the grammar and see the issues.

In all my work on the grammar I have found maybe 2 or 3 places where
the grammar could be "extended" but it isn't so much extended as it is
regularized, where some parts of org already parse a more complex
grammar while other very similar parts choose not to. Overall the cost
of not parsing certain forms in certain situations adds complexity
rather than reducing it.

The situation for contribution is also further complicated by the fact
that the elisp implementation of org mode is internally inconsistent
in its behavior with regard to the syntax, so great care has to be
taken if someone tries to make and argument based on the behavior of
one component.

All this to say that the need for a conservative approach to changes
and extensions combined with the internally inconsistent behavior of
different parts of the elisp implementation means that the
introduction of new features is extremely difficult because it is hard
to predict the consequences on other parts of org.

Overcoming this is why I started working on the grammar, because
in the absence of a formal spec for what org should do, it is very hard
to make changes to what it is currently doing without having nasty
side effects.

Best!
Tom

0. https://github.com/tgbugs/laundry/blob/next/laundry/parser.rkt note
the upcoming path change (which I will note in the original thread when
it happens).

PS I'm planning to reply to the main thread as well. My short take is
finding a dedicated and responsive maintainer that can take over from
Bastien is a high priority. The only other thing that might help is to
have some way to track outstanding and closed patches, issues, etc.
that is more accessible than trolling through years worth of posts on
this mailing list, but that is a can of worms that has already been
shot down multiple times.


  reply	other threads:[~2021-04-20  8:21 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 18:43 Timothy
2021-04-17 23:29 ` Thomas S. Dye
2021-04-18  1:56   ` Tim Cross
2021-04-18 19:39     ` Timothy
2021-04-18 22:45       ` Tim Cross
2021-04-19 21:43     ` David Masterson
2021-04-19 22:21       ` Gustav Wikström
2021-04-23  0:16         ` David Masterson
2021-04-19 23:46       ` Tim Cross
2021-04-20  8:21         ` Tom Gillespie [this message]
2021-04-23  0:34           ` David Masterson
2021-04-20  9:28       ` Jean Louis
2021-04-23  0:38         ` David Masterson
2021-04-18  5:04   ` Timothy
2021-04-18 18:45     ` Thomas S. Dye
2021-04-18 19:12       ` Timothy
2021-04-18 19:46         ` Thomas S. Dye
2021-04-18 19:59           ` Timothy
     [not found] ` <a64adc3de7be49039372851ea31e4f7c@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com>
2021-04-19 10:04   ` Eric S Fraga
2021-04-20  3:54     ` Timothy
2021-04-19 22:07 ` Gustav Wikström
2021-04-21  9:33   ` Jean Louis
2021-04-21  9:50     ` Tim Cross
2021-04-21 10:25       ` Heinz Tuechler
2021-04-21 12:55         ` ian martins
2021-04-21 13:07         ` Timothy
     [not found]         ` <1c557c0e35e04440ba2dadfe57e5b590@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com>
2021-04-21 13:27           ` Eric S Fraga
2021-04-21 15:31             ` ian martins
2021-04-21 15:38               ` Bruce D'Arcus
2021-04-21 19:35                 ` Tim Cross
2021-04-22  0:36                   ` ian martins
2021-04-22  0:48                     ` Tim Cross
2021-04-22  2:35                       ` Timothy
2021-04-22  5:14                         ` Maintaining babel packages — a list of packages that need help? Dr. Arne Babenhauserheide
2021-04-22 10:10                           ` ian martins
2021-04-26  7:25                           ` Bastien
2021-04-22 10:00                       ` Concerns about community contributor support ian martins
2021-04-21 19:31             ` Tim Cross
2021-04-25  4:30 ` Bastien
2021-04-25  5:52   ` Contributor Steward role (was Re: Concerns about community contributor support) Timothy
2021-04-25  7:13     ` Bastien
2021-04-25  6:17   ` Concerns about community contributor support Tim Cross
2021-04-25  7:19     ` Bastien
2021-04-26  0:23       ` Tim Cross
2021-04-26  5:00         ` Bastien
2021-04-26  6:07           ` Tim Cross
2021-04-26  7:34             ` Bastien
2021-04-25 10:10   ` Help with reproducing bugs reported on this list (was: Concerns about community contributor support) Bastien
2021-04-27  6:28     ` Help with reproducing bugs reported on this list Bastien
2021-04-25 21:40   ` Concerns about community contributor support Nick Savage
2021-04-26  7:22     ` Bastien
2021-04-29 14:07 ` D
2021-04-29 14:16   ` Bastien
2021-04-29 14:44     ` D
2021-04-29 14:29   ` Ihor Radchenko

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='CA+G3_PM=HK_L7+8aD7MwjwEDvT7uR0QmS0w-S8NWKnZibm2Mgw@mail.gmail.com' \
    --to=tgbugs@gmail.com \
    --cc=dsmasterson92630@outlook.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=gustav@whil.se \
    --cc=theophilusx@gmail.com \
    --subject='Re: Concerns about community contributor support' \
    /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

Code repositories for project(s) associated with this 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).