From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id Djq0BIuE6mBNQQEAgWs5BA (envelope-from ) for ; Sun, 11 Jul 2021 07:41:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 2KJxO4qE6mD5IAAA1q6Kng (envelope-from ) for ; Sun, 11 Jul 2021 05:41:30 +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 626181F48D for ; Sun, 11 Jul 2021 07:41:29 +0200 (CEST) Received: from localhost ([::1]:56192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2SDX-00089d-CN for larch@yhetil.org; Sun, 11 Jul 2021 01:41:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2SCR-00089T-P6 for emacs-orgmode@gnu.org; Sun, 11 Jul 2021 01:40:20 -0400 Received: from sonic317-22.consmr.mail.gq1.yahoo.com ([98.137.66.148]:44194) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m2SCP-0006Qd-36 for emacs-orgmode@gnu.org; Sun, 11 Jul 2021 01:40:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625982013; bh=R71ZyXQroQYlgAqWxV7CaTYjeFymTMuVIxkDLVaf1sg=; h=To:From:Subject:Date:References:From:Subject:Reply-To; b=K+3FMb/NwvQfeCKX5i0ZlhQpgjHC3L59xWunmHWfOTfXoRr3x35NTdam1LQcAXnNc15ctLj7qehMLaKYyhswsNym5U5KzNsCUKz732VxQThH3nftmuRs+ZT80rcum4XHo1zDxJJ1vG023OrSwwlX/eyG+4OoHzmUYtZ1OOIsXsuIxMP5FcoKo50FSay9BI7ZqtkBoxs7ZkASl/ZNfWnHFY+ZoX/ewWUYWQ1HiNXXMKw4Eyz05yc6+J1he3vOSeBFjSbi/5GOFfFt6lwdMy/Ng0tspLdvh/2Z68IEz1r0UEcCMBq9vAmk0+GKEHhn4/hrmozXVDb+U6UvvK/ds+56dg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625982013; bh=7Ih3AJPo8mxNL97b8xsmp61BDmW9F+N9oQt3zEGE/Ng=; h=X-Sonic-MF:To:From:Subject:Date:From:Subject; b=NNBKXF/pfs4cFA0VCEcWExVIy0vm1COxgPbpOcEcQ1TtaAB48cOMxmlFSUflVj5E2ApMq4QYttGLKIzqr1BwK/NKwvje9VzDfIPHTYq5ipnyxPzhX5tKXnDLmfwJuIbRvc7nfuf7Xs4xFqflN9mogB50er0wPUDSwpwFiX8f2ALNMm+XLXJ0ZdnCbh9oCCFWPcon0Mw5/7BZ+YY3A+PbCVjdLDD/o/7NI3FqBwuOZIaAdiJEw2oOsGrvAuZq+a5ONdPqfXD5AV0Di5sMGl15npMYvVdFzDDBfgdJ4CTpptulnrutEY/ZXhV9+xQrkuNkeXkyie6NS0RA5UMeEXe1lg== X-YMail-OSG: 3KkxthMVM1kkUXCVDByVxb19sP_RLkHHtcCgpAopj_JqelMDu6oPTI2RxU38VHU v86Yq3q9QK_eimeHJ4iyJGHOhPkkJvYmNMMVw5WQwYmhoEfoWMLTATVgDPGAGgzk.vrjJKVvBMTE MzkQ7nTPiyjMKqH6ETRac_0vqzhuD3Y_qt8IyhcgOCohgvrYFS01nFHT5_Isl21uhTsD5NVX.Ywc g5GZucqEc5icQuqoLXc7JiKFT0DcEUmSPc0isd3YodO_IkjugVaM9z0MUr2x5OsJ2xE6Rxtpqatb 1m0c1RHCqWHYGPd_iL4cYP0SWEwoLg4aOHn0k4yabChtoyPs9zRBAKEwIRjuvSz4Ne1jcRggXkKn KNQP8tn7KrJ7pXwv.5R8R1DPM9z3OCfOC2fj6OpFe9MEkqXwCKu4tCnckw1GBSfxkDWpSy2_9PjT EV_tD1xJiB_5IjEbpIKUcmLdqxigTIhkX2v75EicB9PRmgIkiUzP7WlZ_0eNeZddWlo9e24F2.r8 KsG6z6b.zFrHUECxFakOmQ8EOzIpPEGUjdwaRs6iBnBGvs07fl_ODVsUxKmItYZSELyG8imAKuL. RDrSb0M2sgBWvN_pTc0AHfwZU3rvvCW7lzmYT.WrRjmR1Q9DezUNtT4ndk00m5O8PU8qtCFqeLgw FIs.8sZQFb3tuQEFayq298wyLkJH5WnB3X0PAUApNdWKhD4ZLRjnMbusJIbeOBK0mcAla2VitEC_ T423JzH5QoIea70wF7wBA_7ZWUftavg2V0du5V96uTmlET8YXOvFENloK2.PVjuNxsm53GWFc5rQ JbRz34lb39GMJZWAyW6fUtmx_Zr_6x.BkniKDX0FslqdiwhBGgu3QVLcHZfC.qIgrkG3I4SSXVrt hymyod_wymlxq09R8cY.7BM_5f7jySf1RVLq1.hY8X1Gils06rHAuYajxH3EhfFhCUILCWgnPaH3 Khz727vWzuajWrP8dZOoGU6lSYsCLXDofaxXKEpyBGhKHlPXyYYKSPbg3CsWNNDcVLteLlNYPhtp wQWVve7ucmzLE0lU8gvfR6yU60iaXVJWtRCysNj9b6mhL18R2gDuSuCzN7Dpsn5h_rLGpA9O5oWD S0yUrZLHII92AdNCDFqQLPa751.yIYASM5tOBMtQ5NBpnUAgQ3eOdpBp2Q44lxafQKpis2GvsCEO fU_AKmtIG_uu6WnrXlCuH7qynqIj5G9KyNNyuqmT.WrzPGnlDA2wRxDUgfaBsCpDU6SQqfB2j25h LLDb49_uKu1DWSI52UDo2PqU8cthdcX7LJFg4SjEKAvtgtYx8YqksHy5na3UyIVtfMILcFse7Qwz 9U1RExPJzcSzaouPXmXShbCXNIJ8gnD1SHVmVN2jkDuWFxp5ZvFfoWR27ZMI6aji9.k3JQ8Ahr_V _F17HAii6uZX0Tzi3RygQp_RLUUkJFJ35_CduvK2mgApE5UGU7ny3e_fRZx9ueKtTGj3fbbIVUAZ 8LJ2hj0LyR5S42MQS4QB6kbCShYX4_YwOD2Ma7jFD2CxYrpwC9tk.w.S0WSaTZv7OQm20jY44WzB SrvekWjU2JcQUF1DXbav8xWjS5tDM.GvyaBbmDoHM3fqpvMAujd7RYEMVvhTkWVpM8fg8fPGENrT NZmNpqjC0AhpCBBjmknXLQuFM.CU0E0hIGFeiooviVObRf3vhqgRtakkRkvfiM1bsPmYQeiULTOX 2sU3mKcPGS1Po.wMVa9dSuv7TkG9skgleI3YT5kBGs9G4GyPwPWH96AiJHdwi7PCIGHMTsYHs5Dx Ot2xGGKqRsaGkkoLoIWxTW8V599OdTFi5hVx.KBmFYDcOgOTxdzIwJEtpCfkgAHXik0LaeKukq6d 8JdDH4PZNLmtnM73FYv1TQ4I.DXpEyHOxWKZZVxhOxVxrBUjEJg.96WWFj3IVyBkBLgQwqNsOB4F 6T_6ASOGBLS7cBnJdMaUveWWkJEzPENuE__CFxyEqrrJju3q1mc9mY5HefkWL6SWqlAVIgDiSoSl ms56hkGjQYJh0IxarBRs0_1Voa69QYz68_e00yJzjVU5DKCJqdx6k4yxdwB74vcifxtyrhD9.MpK 9stUrYZrF71lQU5W64BUVnDiYVpdbvFbiA2XDJBh7TDrjjvXu24Ua.CFczytbk0suAf4c29FC1ze ZJIaO7Nl4gY_PYim13KWlOvrqtIo_wWOP4rVTw27W._F3k.XYuRQ0C5Rnsw.OEGM64VNRYLoFXil 2X0QIdobfGBkAeCFGXslK8ieXN864V2MiFB2rt8nEP05es8Nt5qg4o4qfpjr9LGDs_bgnO5gV3P7 rj4ie.fzsxs3cmmo4tOYwR31t0h7mPghI.vXq46FxVjLdfWcyrfA5EEbOjVHkGbJx17jZ0OdiPle SM9uAh_9nfjuJH_EVFO6jvQ1i_ccO3RECsk2pzDbU_UrZFcCLHB4efNaIqaPjoKiTYXF71lmiaa0 7hiWGPazxJN49JX6Of4HodAn_CJq5rQ_RSu63W08mLGuNeFQm X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 11 Jul 2021 05:40:13 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ac34abb683b4cee089407b459131369; Sun, 11 Jul 2021 05:40:09 +0000 (UTC) To: emacs-orgmode@gnu.org From: trx2358-gitter@yahoo.com Subject: org-mode linter for BNF? (was Re: Concerns about community contributor support) Message-ID: Date: Sun, 11 Jul 2021 14:40:05 +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 Content-Type: multipart/alternative; boundary="------------5C5E25C9B9E0B9BDFDDFB36A" Content-Language: en-US References: 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.66.148; envelope-from=dougmabroad@yahoo.com; helo=sonic317-22.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, 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=1625982090; 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:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=R71ZyXQroQYlgAqWxV7CaTYjeFymTMuVIxkDLVaf1sg=; b=tOXTG5q0OKI3EBUY6Zc5ev+bJ8MjzpAO73SZO6nL2DOXXrv/CcbwAEDxjbuVWclgqFow2w NZdp2d+Hj4dr2TND4xuocRobGCsPhDnN/r/TxhrUwlohVd1E+AYNfwgF6Bf2iLrCD8Ur+z GPJqcOJyw0Sdee0jDL/6LXkQuqMKKCvroGFiFw9HmJzHIsetCqUtgxC7rN6xI+fLGtiM1v JvDer2ZKg9tb7CSBcitaHcZKEahttBgqpvqgdeUxXF2h+Dh1Tr8r9xSIzGMrkbveA/0JFv YQEE81IjQ9xlME90hMXQm0mbtBHwH25gtPvb5DjSk5glutYlmwfxBNCG/5demQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1625982090; a=rsa-sha256; cv=none; b=rqkMiLrq9D1MVvcBgoFK/Y5EGNGTZ8vwJ3o+CpA4HR2XmaHzLQafwG2eVfTPQdDdw2h/HQ IjvM/vR1Fkmj7lq6A+q1M9QadkQGHohhormhzcoeCiBYkqeL74u2Eio5srQKwBAEc/gBlj 8MRSgxhCRej98C7Qsv1PAtbSCl+3wNHYtpwycHc4KVbr3KxLtj+skRpX7b4cIF6iWC7h9v ISoatEl5Oiv1fIqOzz5xFgZVHDRbpIHvsD1zF+p18CbdqDDC/1N5oAuIWGCdOjejplBTRv SDEM4r8ldEzmTQd2LllDLEmNvnRJINnowFg1l//NbVCyQ8lcrSP9QYlf2gHKIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b="K+3FMb/N"; 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.61 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b="K+3FMb/N"; 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: 626181F48D X-Spam-Score: -1.61 X-Migadu-Scanner: scn0.migadu.com X-TUID: Sj0a/LFSiatY This is a multi-part message in MIME format. --------------5C5E25C9B9E0B9BDFDDFB36A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------ 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 --------------5C5E25C9B9E0B9BDFDDFB36A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
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
--------------5C5E25C9B9E0B9BDFDDFB36A--