From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sELBHgCJ6mCOTAEAgWs5BA (envelope-from ) for ; Sun, 11 Jul 2021 08:00:32 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id sCRhGgCJ6mD3YQAAbx9fmQ (envelope-from ) for ; Sun, 11 Jul 2021 06:00:32 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AFC991F645 for ; Sun, 11 Jul 2021 08:00:31 +0200 (CEST) Received: from localhost ([::1]:41704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2SVy-0003LL-OP for larch@yhetil.org; Sun, 11 Jul 2021 02:00:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49996) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2SUc-0002bY-BA for emacs-orgmode@gnu.org; Sun, 11 Jul 2021 01:59:06 -0400 Received: from sonic303-23.consmr.mail.gq1.yahoo.com ([98.137.64.204]:43078) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m2SUX-0006RR-F6 for emacs-orgmode@gnu.org; Sun, 11 Jul 2021 01:59:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625983136; bh=2yWu4cQsf7YbuKuDFH0bsP0QOmiqoGgjFKEsAsNutKE=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=GlantTYmVgsxvM1KbBZlFND5qnsIniehsQgiLlfg30nMZvKiHsTNubfRV+TW0t8tiHiFTtcr076uBRP75RyoMh0S5yM8cfNbD44ass0wlgPnuAh98U3mLdmh1sJbaaix1vwPxNjQq6IqjgqC884t2KfyJgfpxJIx36bqVLNsvOgm0LNd+oBEbNnsb36ex3r7dUvAnFq975UZ7/7xClwa7YeT+3eaVOahiStyjn10e0aYVlWcoDoaelEGx+Ws9AUCzjTceHCbn1r70YI1KTAKewqS4Afi15EesnZ07KVp9T1+UXHfRuQkrPGrcSt/ZttDlVp4irQxF73IHGEB6iiGhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625983136; bh=o/7ee+G3faTlIxgMF+d4P9PPKZl5Fwbii7P6Own7Gvo=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=CkCXKYTrz6Ma2h0N36vvWFBUn43TPgS7DrxBTvItu1nb3AHVpmPCcZPrvW5K2civP15MbL71O9qFL/JZLbgkHSRWGUZfv9va8Z3Ceny04Jl8KHm3vSee/R3FGE74H/Qe0k3ayaAXdoQjpJf2g/Kij7H0c9rGVfXqGqnK8DJ9SRZ7K9Iy89C4f6HCNsXjf2QLimZkqu5UQvGJlp0tpa2WS35ITlArMqSlcSRdsTfzOglxwiwc5ovxE4NOQKCIFLXg7rVBG28Ea596wtm44Num4SRLiTlOmFLLzc/wIQSXQjNPIOHxbjdBIxiAdh4LJRu278lSehaUSfSdHhqMDZ9Kxw== X-YMail-OSG: QXW316oVM1lEm9fAchrQn.1AJFcUB4LQd_ORt41bWjq61ZdWaRo3zxwhVmX3ch9 SxjueydyJr8K3jtEa0D0eg0dDfauFI.k.LMLyGyLxvUiNsg6g8FW8Bb2Uvv8_uI1ndI91TZoYotb xKSdQNJ.j4mDz1RilXnohc49xYgXztMNzb6B3K1xllHGPDV6y6sFsxbimqFaKHgyH39jtQubXtsU t7sLl9jOg8Q1sHEv3YnxgJG_oIwU6OKhpgSUcNwKW_Xpfa8SGgGd65Z0kJqutLmkDgSjde8C.zt9 sXBoTVp3rKvJyJjs0Ybyi8TFid8i4Qzom.OeYyq_7jokqrpFo3mlh1VO0HuM65yzzvnCOe7Xk9GS gr7hmXZVkXgv40ffJxcO05jWE4LQGphF5sGsGRkzF2GPLv6WjlMh7gfyvUbCudctkVPKbtPwCOyl Eu5QF1ClBunahqbB1PZxW13U92m4sSPcD4dDfqGY_id2FuGNZUryN1xJIRkSiX6XWXt4jwv2mLJ1 pZ9zlnymg0CukDH2Phk0Lu_SJHDtPBjZUPHWbgPS9b4g9oj.wm6ptukoT_jZ84vu1D45uCfZVeI3 xpelc6y.Rfzsj_dmfx3TUPUMI9ReQui_wEIaS2VJhM3P.Fu9MNahXopRKE0E2sMsDMLmqDX0BMCJ 2g1MSDOVq1umxWZVzcWsmW2dacR7VPIbiQH19AVdCxlmg5nwlysoJ_9yXmFleEUFu00.dshDGyqC DFudc.hFk_YN9Iipjmhr1Uy5yzwFC0meldE7fDBKlC8WssKp_uf.W.rMjeni9Fk.kzMn5aJ4XLb3 SeLoI8iRQgwdKiaf33DXZCBteW40UmWJRzYikxXMDh5CW6FZD6GWJ6__oGtjjSPYQZz8B42O7jAH Hhet41CKEwzfAI8zmEYriAxpenijXgsk_MOn8iY37V7mtiAcAPYTcJBKL.cXaffK.5r6LCx52G0m MPLCDDKlHcJpKnELhk.nizfOqkbCL0MDfZuqeGW.RtOms9HtPRXWdXxb53xBw4baVXyQWu3EVTzd 3qugBw_lBPjbwOqHHrF5VfTAM8uSw2Opgy6WrSvETpzRU4WyVzgnlYUTCXBF2crWGTjS0Jxgoa54 Q.lqjrb4snf9_cM.hIIzcz8Cw9P1eo1JBgaV9tgKfY2L4DWpaKqq96qlOP.EpHmvy0FoA3ntBdo2 TBmxmX2gl66V_fjzKHOYAguc5.9wjx7JhTxyD4zwiuu872QGLTtl7S.Wx9txkl56kp1gZH7w10xA DXSqepIIdRER99mZpDywj8dXkYvgvddKLnbfUYu.WOd1Q1CI4llzC6zMabSrYJabn46MFgiYSz2b HVMXgJeHt70r9tJljVxYbl5u5q0ZonWh56Q5.BP2pSUWWQ9XhMpaFIyQoip1nUnuAKfbIQ10fYWr cVXMmlwwxc2RxfM5mvUcjXE02mnXF4YfNOBG7RK95auOQjk9no0jifuV7NJaISWNSTuB1ADUmK3r bUxlbOIEoUIJyu6kdsWWoxbxxQSDa5bfYjBOPKhv2zzyZGd0wjRPtyiMV3Npe3X6uw9UTkUxLdSG Be0P1vvpSg4GnkFsIPi7dUtiROlFDkyGJ0NBDZdZ__pTRMJ5BSJWNFnP0Z_YJ.FDWCXtYD4Mu79M 9CS7k6W6LmGRmxGYuHQpXUoz5gzip_0RE6iXQ4YJvHXN80dVWmXwPi0wxs_VeqLRqYSVO6zpANOv Nejg9tEHSsh.akqNR0aakCr2T.EPDyV6ZSKoefSIorXE5J2iy._7Wm6zrta4.zpRSv5tTkhevy9P qx3GkxlGYD8WMB8cnO0D.xesW7oQcRko1jAGVohpJQ9Lrd5eJRCyliLLasZ_u0omhId.vvB8jAq5 QqQFz_8Y2nbWnX9GkWWjLP3wIlwcmiWLPxE7t1PBzBiFD65tPbg2e07YHXA4TV3wWNEzaoTwLQyk l78fbvgYrLo.dUoINGGX4pVYVomnuIFc50s2ph_uNpBspd5yxQs1_2YfH3E3uYBuK9bngqF8qz_t ZbyN7YxQNMoVEQdABBTkHyugU643RAbEiBwIhg9RO2TsIUdujEl4KBQhwq.YOwFWzjKKHxIg5SaU 5nZUygPvrWA63CcCSm79iaRc7.UtgvywnA9L54IB.n4Oit7De.R3W1Ma7ATJzEX1G4u0IS76h3wY FtvbSZRF7BeVuAxFLI0K2L0VZzR8jvbMbp.IvLiqi2LP0d7o37OeBjIE9q38Zmev7NqGCDhn2Nqy LIl.BXGKto1ndu74veEAL1gbbfHGJCBT8UDbkP8quBNSyaq0vdJXeR5LsK0BBkHxu2H8v42cVpgo 4ziy4beZ.4U37LiABOwQAzf8jW3JoTdFjsEk5kpOSB7D1ttl3.7.SbYrPGhVEOn.K3c8hCEcZwII hrq4njNeW84dkjFvqFFprEfynAXXV1hAEbkOiskowxzWfKcHcdJQGHcir2ba.YX5OFNYP.3AQ5cM WzSbd2KTC2bh2OpU1qa9TjchNEUGx_knRUb7aLB__i83XB2yaUg3gfEb2PYgs X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 11 Jul 2021 05:58:56 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2e03945a9abf57167288876f2972b126; Sun, 11 Jul 2021 05:58:54 +0000 (UTC) Subject: Re: org-mode linter for BNF? (was Re: Concerns about community contributor support) To: emacs-orgmode@gnu.org References: From: trx2358-gitter@yahoo.com Message-ID: <28097ae6-bd9a-6842-7600-97b220375fbb@yahoo.com> Date: Sun, 11 Jul 2021 14:58:50 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D0FF152B1943E3231004696C" Content-Language: en-US X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=98.137.64.204; envelope-from=dougmabroad@yahoo.com; helo=sonic303-23.consmr.mail.gq1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1625983231; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=2yWu4cQsf7YbuKuDFH0bsP0QOmiqoGgjFKEsAsNutKE=; b=oNfTHt9ozkYp9N6rmE5O2vDgjPkrhpKFqEvT+zKt/YUvVjBAUD5gLmcDToDgmmLU6y5HEN dSGg5azqHgRvPNwoota/KOjFvYpywJxfnMvH+qPgsSD0hQS41ZWk4PNFKy1JrKSppUsFn5 FBgCBQC9YZv2RGz2XpCjEPRdSvy1zpmqquvRzKCsRUoLY1rqBb5EDRPHsrNiUiB/vUjYaC oqyjfwep5yvRMAgQ1l4g+tP7kX8ujDeLfiL5whkCxISxvbOxkWDK31VNeSMkPLzwkkjWhU 4dMSxQz+JDFjd2b7TDRvGspCZf1G931+GVZK9hT6ajzqNVxTl/kVBEcOPfViJg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1625983231; a=rsa-sha256; cv=none; b=uD1P290l1UjyCA+A+KUI09IVxAQ1yxxn0d7GzQ63BH7tulptZKl2IBVxG8j90qjnOKbDn5 dnmq93Uk17FORXVf8va/ZVy65xlnNEaqBoIv5JcNbWJAJK/tMe4gJ+3PanBRux2GMmm8S7 uA9f0qKLm6vHfqDQihYxftqQ8Wy7yYZqCqHDVl6H5SKgE9IRiQ5iY3gh/+jkFdedX1WMnR KRLJi6Xdo3srJLRbj2O+4u+ILVhTRdUph+GcAnix2IE77VdXpTljDkfnJ02wiqsrTpWYtC Hv6KqzZmjz6Jqf75vJY4nhRbZjwiJwbh1c62sbuW4iKpRALAz2rJY14LJus7YA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GlantTYm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -1.60 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GlantTYm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: AFC991F645 X-Spam-Score: -1.60 X-Migadu-Scanner: scn0.migadu.com X-TUID: j1EIq3+vUk3+ This is a multi-part message in MIME format. --------------D0FF152B1943E3231004696C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 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 > 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 > > --------------D0FF152B1943E3231004696C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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 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
--------------D0FF152B1943E3231004696C--