From: Tom Gillespie <firstname.lastname@example.org> To: Tim Cross <email@example.com> Cc: firstname.lastname@example.org, emacs-orgmode <email@example.com>, David Masterson <firstname.lastname@example.org> Subject: Re: Concerns about community contributor support Date: Tue, 20 Apr 2021 01:21:01 -0700 Message-ID: <CA+G3_PM=HK_L7+8aD7MwjwEDvT7uR0QmS0w-S8NWKnZibm2Mgw@mail.gmail.com> (raw) In-Reply-To: <email@example.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  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.
next prev parent 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://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' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ email@example.com public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git