From: trx2358-gitter@yahoo.com
To: emacs-orgmode@gnu.org
Subject: Re: org-mode linter for BNF? (was Re: Concerns about community contributor support)
Date: Sun, 11 Jul 2021 14:58:50 +0900 [thread overview]
Message-ID: <28097ae6-bd9a-6842-7600-97b220375fbb@yahoo.com> (raw)
In-Reply-To: <cf8571f1-082e-49a9-0129-02be771f859d@yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]
I can even imagine some productive interplay between a linter and
org-mode itself. For instance, the linter could be used for deprecating
features in org-mode which are no longer maintainable. I'm sure we
could come up with other examples.
On 7/11/21 2:40 PM, trx2358-gitter@yahoo.com wrote:
> ------------------------------------------------------------------------
> Hi there,
>
> I'm new to this mailing list and I'm sure I'm not caught up on discussions on using a BNF for org-mode.
> I have seen Gustav Wilkstroem's warning about the difficulties involved. I wonder if I might propose
> (what seems to me) a novel approach. Maybe instead of using the BNF inside org-mode, the BNF can be used
> for a companion piece of software which runs alongside org-mode. As a sort of "linter" for org-mode.
>
> Taking code editors as an example. During editing the code need not conform to the spec, but once saved
> and handed to a compiler, it must or else the code will break. Tools such as [[https://emacs-lsp.github.io/lsp-mode/][lsp]]
> run a companion process alongside the editor which continuously check for conformity to the spec (and more!)
> and report back any issues they've found.
>
> If we had an lsp server for org-mode, then third party tools could be written to what *that* accepts rather than
> what ~org-element.el~ accepts. Tools could specify that only files which pass "linting" can be expected to work
> 100%. Of course other editing tools could also incorporate the lsp server to have linting available to them.
>
> In this way the specification of what's "pure org-mode grammar" is separate from "what's possible in emacs with
> org-mode". Obviously we wouldn't want the two to stray too far apart, but the added flexibility seems like it might
> be a boon to the community. It would be good though if such a tool were "part of the org-mode family" rather than
> developed independently.
>
> What do people think of the idea?
>
> -Doug
>
> FWIW, on a somewhat related note, I've started a github repository of org-mode snippets with the thought that these
> could be used as examples to discuss what should and should not be part of "pure org-mode grammar".
> ([[https://github.com/gitonthescene/org-mode-samples][org-mode-samples]])
>
> As such I'm actively seeking input since discussions with myself seem to mostly go in circles. :-)
>
> Also, I've laid out this same argument with slightly different wording in that project
> [[https://github.com/gitonthescene/org-mode-samples/discussions/2][here]].
>
> Tom Gillespie <tgbugs@gmail.com> writes:
>
> >/Hi Tim, David, and Gustav,/
>
> Hi
>
> >/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./
>
> What do you think about having multiple Org grammars that parse specific
> parts of an Org file and treat the rest as text blobs? The idea is that
> small tools (on smartphones) could concentrate on (say) gathering and
> using the info related to one of:
> + task management
> + tangled code
> + Org file options
> + etc.
>
> >/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./
>
> How complete do you feel this grammar is?
>
> >/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./
>
> Hmm.
>
> >/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./
>
> Thanks for the effort! This could lead to Org developments on non-Enacs
> platforms (smartphones & tablets)
>
> >/0. https://github.com/tgbugs/laundry/blob/next/laundry/parser.rkt
> <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)./
>
> I'll see if I can look at this -- it's been decades since I played with
> grammars.
>
> --
> David Masterson
>
>
[-- Attachment #2: Type: text/html, Size: 5810 bytes --]
prev parent reply other threads:[~2021-07-11 6:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cf8571f1-082e-49a9-0129-02be771f859d.ref@yahoo.com>
2021-07-11 5:40 ` org-mode linter for BNF? (was Re: Concerns about community contributor support) trx2358-gitter
2021-07-11 5:58 ` trx2358-gitter [this message]
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=28097ae6-bd9a-6842-7600-97b220375fbb@yahoo.com \
--to=trx2358-gitter@yahoo.com \
--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).