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 sPFfJmL/q2H7SAAAgWs5BA (envelope-from ) for ; Sun, 05 Dec 2021 00:53:06 +0100 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 aAEkImL/q2EHSgAA1q6Kng (envelope-from ) for ; Sat, 04 Dec 2021 23:53:06 +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 2A5F0DD8D for ; Sun, 5 Dec 2021 00:53:05 +0100 (CET) Received: from localhost ([::1]:39800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtepy-0007GA-Gb for larch@yhetil.org; Sat, 04 Dec 2021 18:53:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49996) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtepR-0007G2-2K for emacs-orgmode@gnu.org; Sat, 04 Dec 2021 18:52:29 -0500 Received: from [2a00:1450:4864:20::42a] (port=45024 helo=mail-wr1-x42a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mtepN-0006Zj-RJ for emacs-orgmode@gnu.org; Sat, 04 Dec 2021 18:52:28 -0500 Received: by mail-wr1-x42a.google.com with SMTP id l16so13932254wrp.11 for ; Sat, 04 Dec 2021 15:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew.cmu.edu; s=google-2021; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jww/dxIIWM0tcmFCHCGEOFBd4oqKGxJPXIsIHtMTNZ8=; b=fKRJNiHuL3fEpP4qiW2OcIB75GSnjT+uWKXNVJ2q426Wcc1+tKhzE3ymnJ40nQ6ASF gkTJIVgIP0gjavMvwYc760YvqPFgppmPrW3Tf5aNwcWeR+rn5x8TCn82JNqfLLlVKJm0 MnA4mReNWN9jRtgYH/h42pJFjaswuvSK2IzgswQULcha8XOttfIJ6sVsbC9yRuHmW8YP XscmZ8kzu/nWp8O1iqYuSI79SJ+VV/7qf1keYlKXdc3DC5OFBFbznb6Cm5tBeq9mYjsd kFqrQkyoZGTw7cOACMYPRw3mX7Kb4iU9yfKcqGTUNePBO0tIVXvSE6r5BYkExqtJo/to uJ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jww/dxIIWM0tcmFCHCGEOFBd4oqKGxJPXIsIHtMTNZ8=; b=RdEKXC+NWzMRi+WJY/M/JEBRk5C/VmM+A5aLyZ2ZE65WWHWB/Q774FKjRrr3gxFF2p WxVWNh/H25FsDCWNdQVPrNgCQuaLBYxKCEcvVBVrHWBUbsuFyFme8LV605M8sqC41F90 aJN/vo4WLBr6ke4kKVKuHdS02J+we4skxDYqaxS/1J+UW9gSnEUMZa9VvyDiXljMyAOM G3EuD14qs94iYEOIFotzNMqK5cP3WcQdPDzZ7J63E3NeAMQpyMYD+E4DRmlWkRmWbNnE tp6ll3UstjJV7M8ssOJ2jF0S2aa85GpsuzeuB2/CTta7ia6UpcahWyrGkEGT8MTO6g/z CHxA== X-Gm-Message-State: AOAM531e81rCCc/BDsCEYw9WFSnOO2Twqa1EUW+8TX7KP4fWRQImQqYo f39PeRep4ytyfUSTDFdcWZy80ogqXanNOSWiUww8KlESaqY= X-Google-Smtp-Source: ABdhPJzerW+C70PDEMO6mzLgO5yhiEtg8uZuwikJL5k4mWPPmGlbSmEJQPC6h0bfbKNW5bqMPkHkx1Wv0j+rLyNLT2I= X-Received: by 2002:adf:e60e:: with SMTP id p14mr32579790wrm.470.1638661944150; Sat, 04 Dec 2021 15:52:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Kitchin Date: Sat, 4 Dec 2021 18:52:13 -0500 Message-ID: Subject: Re: [fyi] extensible syntax, syntax features, parsing risk To: Samuel Wales Content-Type: multipart/alternative; boundary="000000000000168e9205d25ab7f0" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::42a (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=johnrkitchin@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: 13 X-Spam_score: 1.3 X-Spam_bar: + X-Spam_report: (1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_DOTEDU=1.997 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638661986; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=Jww/dxIIWM0tcmFCHCGEOFBd4oqKGxJPXIsIHtMTNZ8=; b=bQrrw2PyI56yIoFrX4osa8RHP0/4mkkUX/dpz7ZetKzdtMOx9eE/CM7rwdXI6YjKUT/HSp fSNRWtCQX9RD52lZ+M3vtSbzzRkX3Nn/DQIpggd38iWxm4Y38fEbVtVTH3qtvSX2utDjYF CkGhSA7mX8sam3JkUldZMR8klrwB1pPfJcvrQpHk4OR79y/XkrJXzOHQ11qI+NReAghE/F Dpg7+XuudnbTmmtbhPhCr0+Dy5J5ORlDz/ii/bDcON+ehE8GRInIp6BUOFoqoK/Fq55YRW P0ZEpOljr+inC6pt+h9Yz7Xy5xtL9qJZkyn2jp/oPs6Zsw/s9E5ElV8Qxh+TtQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638661986; a=rsa-sha256; cv=none; b=Dt6Ug9dhB9C+iD43LXnWvsFRuylN0HvsHe+c7Mtlv8X3mH5fcboph0pct1XB6BujeoI+Kc KjnqTtBcN2jRE1U/L1/SbBqdu7h+mQmofWOfSqfO6fHH8NSHi6VOCiCxjZ+QaMT+Nd19// Hvnq2ELJRv0fvjZToggeladxHNw3ajujQLNw/p/dRzY3dX5sgGvoOM/Eg7arAg8iRf2kj7 5+6PAVDlz7h1sT8WvBUuKw9q/2yW1zg8hhoEsqsxSaxjjZUlJahSRvTNT7+6UIP4xU01hk wHIiTdB0EX1qee4Gk8bZosaTS0cMNmoB9hFAM1Ao5xM5O/z5W5yZ4uGNNMT4eA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=andrew.cmu.edu header.s=google-2021 header.b=fKRJNiHu; dmarc=pass (policy=none) header.from=andrew.cmu.edu; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.13 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=andrew.cmu.edu header.s=google-2021 header.b=fKRJNiHu; dmarc=pass (policy=none) header.from=andrew.cmu.edu; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 2A5F0DD8D X-Spam-Score: -5.13 X-Migadu-Scanner: scn0.migadu.com X-TUID: ji+vHerrXAnL --000000000000168e9205d25ab7f0 Content-Type: text/plain; charset="UTF-8" Is it related to https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html I implemented that idea for fun once: https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ John ----------------------------------- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, Dec 4, 2021 at 5:10 PM Samuel Wales wrote: > the quoted post below, which had message id > 20524da70901041233g105f372fv175a47dc9884fa43@mail.gmail.com , starts a > thread relevant to the current discussion of syntax, at least > historically, maybe practically. could not find it online. > > there were succeeding threads with examples and other stuff for id > markers and graph-theoretic things and other examples, where you as > user could always use a cl-like syntax [i.e. something like > "$[functionality-name arg :keyword arg]"]. my main concern was the > proliferation of syntax, and the risks of that [e.g. parsing] and > wanting the ability of factoring of syntax features. > > display, parsing and so on would be shared [factored] among all the > different such features; org would always handle that the same. thus > as a user even, you could add some new feature in lisp, and write it > in org using this syntax. it would already work. > > i have more in notes. idk if it is still relevant, but i have > included the thread starter for the earliest thread [carsten/myself]. > > On 1/4/09, Samuel Wales wrote: > > A general idea, which might or might not be useful. > > > > There are occasionally questions about syntax, like this: > > > > Also, I'm afraid definition matching regexp won't play > > nicely with text indentation, ... -- Paul > > > > Or this: > > > > What would be safer? -- Carsten > > > > I like the footnote implementation, so this is for future > > features, not necessarily footnotes. > > > > One issue when implementing new syntax (or changing existing > > syntax or cleaning up code) is parsing risk, which I will > > define as the risk that the syntax and the regexp or > > matching code: > > > > 1) conflicts with user text > > 2) conflicts with existing features > > 3) will be hard to maintain > > 4) constrains future features by making them conflict > > syntactically > > 5) makes you run out of syntax to use in the future > > 6) will require complicated regexps > > 7) doesn't readily handle stuff you might want in the > > future, like being combined with another feature > > 8) will be hard to quote, escape, comment, *boldify*, etc. > > 9) doesn't handle nestability, print-readability, > > pretty-printability, syntax coloring, etc. > > 10) will be inefficient when called in a loop > > 11) isn't factored out > > 12) etc. > > > > For example, one of the many reasons for using org-IDs (:)) > > in the conversation manager (as proposed) is that there are > > already functions to parse org-IDs, so a new syntax is not > > necessary and therefore parsing risk is minimized. > > > > In case parsing risk is a concern when adding a new feature > > to org, here is one idea: have a generic syntax that is > > extensible with keywords. > > > > The idea is to have a bracketing syntax with a reserved > > keyword as the first element that says what you are doing. > > > > To use footnotes as an example (this is not a suggestion to > > change footnote syntax, just an example that can be used for > > future syntax): > > > > You might use something like "here is some text to be > > footnoted $[fn apple]" to specify the footnote link, and > > "$[fn-target apples are delicious]" to specify the target. > > > > The general point I want to make is that once such a syntax > > is decided on, many future features are possible without > > introducing parsing risk. > > > > For example, you can implement a new feature as > > "$[my-new-feature ...]". Then there is no parsing risk, > > even though you have just added a new feature. > > > > For modifications of features, you can use keywords: > > "$[my-new-feature ... :myparameter ...]". These are easily > > parsed by standard functions for parsing lists. > > > > You can develop ways to boldify, quote, nest, prettily > > print, etc. this syntax, and those ways will work well with > > all future features that use it. > > > > Of course, the dollar sign and brackets are not the only > > possibility; it could be percent sign and parentheses, for > > example. > > > > You will not be starting from scratch. Lisp has already > > worked out many of these issues. > > > > I will leave it to those who write massive amounts of org > > code to decide whether an extensible syntax might be useful > > to reduce parsing risk for future features. > > > > But I thought that I would propose the idea in case it is of > > interest. > > > > -- > > For personal gain, myalgic encephalomyelitis denialists are knowingly > > causing further suffering and death by grossly corrupting science. Do > > you care about the world? > > http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm > > > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > > --000000000000168e9205d25ab7f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is it related to=C2=A0https://lists.gnu.org/archiv= e/html/emacs-orgmode/2010-08/msg00404.html


John

-----------------------------------=
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department= of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15= 213
412-268-7803


On Sat, Dec 4, 202= 1 at 5:10 PM Samuel Wales <samol= ogist@gmail.com> wrote:
the quoted post below, which had message id
20524da70901041233g105f372fv175a47dc9884fa43@mail.gma= il.com , starts a
thread relevant to the current discussion of syntax, at least
historically, maybe practically.=C2=A0 could not find it online.

there were succeeding threads with examples and other stuff for id
markers and graph-theoretic things and other examples, where you as
user could always use a cl-like syntax [i.e. something like
"$[functionality-name arg :keyword arg]"].=C2=A0 my main concern = was the
proliferation of syntax, and the risks of that [e.g. parsing] and
wanting the ability of factoring of syntax features.

display, parsing and so on would be shared [factored] among all the
different such features; org would always handle that the same.=C2=A0 thus<= br> as a user even, you could add some new feature in lisp, and write it
in org using this syntax.=C2=A0 it would already work.

i have more in notes.=C2=A0 idk if it is still relevant, but i have
included the thread starter for the earliest thread [carsten/myself].

On 1/4/09, Samuel Wales <samologist@gmail.com> wrote:
> A general idea, which might or might not be useful.
>
> There are occasionally questions about syntax, like this:
>
>=C2=A0 =C2=A0Also, I'm afraid definition matching regexp won't = play
>=C2=A0 =C2=A0nicely with text indentation, ... -- Paul
>
> Or this:
>
>=C2=A0 =C2=A0What would be safer?=C2=A0 -- Carsten
>
> I like the footnote implementation, so this is for future
> features, not necessarily footnotes.
>
> One issue when implementing new syntax (or changing existing
> syntax or cleaning up code) is parsing risk, which I will
> define as the risk that the syntax and the regexp or
> matching code:
>
>=C2=A0 =C2=A01) conflicts with user text
>=C2=A0 =C2=A02) conflicts with existing features
>=C2=A0 =C2=A03) will be hard to maintain
>=C2=A0 =C2=A04) constrains future features by making them conflict
>=C2=A0 =C2=A0 =C2=A0 syntactically
>=C2=A0 =C2=A05) makes you run out of syntax to use in the future
>=C2=A0 =C2=A06) will require complicated regexps
>=C2=A0 =C2=A07) doesn't readily handle stuff you might want in the<= br> >=C2=A0 =C2=A0 =C2=A0 future, like being combined with another feature >=C2=A0 =C2=A08) will be hard to quote, escape, comment, *boldify*, etc.=
>=C2=A0 =C2=A09) doesn't handle nestability, print-readability,
>=C2=A0 =C2=A0 =C2=A0 pretty-printability, syntax coloring, etc.
>=C2=A0 =C2=A010) will be inefficient when called in a loop
>=C2=A0 =C2=A011) isn't factored out
>=C2=A0 =C2=A012) etc.
>
> For example, one of the many reasons for using org-IDs (:))
> in the conversation manager (as proposed) is that there are
> already functions to parse org-IDs, so a new syntax is not
> necessary and therefore parsing risk is minimized.
>
> In case parsing risk is a concern when adding a new feature
> to org, here is one idea: have a generic syntax that is
> extensible with keywords.
>
> The idea is to have a bracketing syntax with a reserved
> keyword as the first element that says what you are doing.
>
> To use footnotes as an example (this is not a suggestion to
> change footnote syntax, just an example that can be used for
> future syntax):
>
> You might use something like "here is some text to be
> footnoted $[fn apple]" to specify the footnote link, and
> "$[fn-target apples are delicious]" to specify the target. >
> The general point I want to make is that once such a syntax
> is decided on, many future features are possible without
> introducing parsing risk.
>
> For example, you can implement a new feature as
> "$[my-new-feature ...]".=C2=A0 Then there is no parsing risk= ,
> even though you have just added a new feature.
>
> For modifications of features, you can use keywords:
> "$[my-new-feature ... :myparameter ...]".=C2=A0 These are ea= sily
> parsed by standard functions for parsing lists.
>
> You can develop ways to boldify, quote, nest, prettily
> print, etc. this syntax, and those ways will work well with
> all future features that use it.
>
> Of course, the dollar sign and brackets are not the only
> possibility; it could be percent sign and parentheses, for
> example.
>
> You will not be starting from scratch.=C2=A0 Lisp has already
> worked out many of these issues.
>
> I will leave it to those who write massive amounts of org
> code to decide whether an extensible syntax might be useful
> to reduce parsing risk for future features.
>
> But I thought that I would propose the idea in case it is of
> interest.
>
> --
> For personal gain, myalgic encephalomyelitis denialists are knowingly<= br> > causing further suffering and death by grossly corrupting science.=C2= =A0 Do
> you care about the world?
> http://www.meactionuk.org.uk/What_Is_ME_= What_Is_CFS.htm
>


--
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

--000000000000168e9205d25ab7f0--