From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sOcmFCnQpmEHDQEAgWs5BA (envelope-from ) for ; Wed, 01 Dec 2021 02:30:17 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id AKnsDynQpmHFVwAA1q6Kng (envelope-from ) for ; Wed, 01 Dec 2021 01:30:17 +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 5D41A30E62 for ; Wed, 1 Dec 2021 02:30:16 +0100 (CET) Received: from localhost ([::1]:45994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1msERq-0000mo-R7 for larch@yhetil.org; Tue, 30 Nov 2021 20:30:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1msER4-0000mS-VE for emacs-orgmode@gnu.org; Tue, 30 Nov 2021 20:29:26 -0500 Received: from [2607:f8b0:4864:20::1032] (port=52005 helo=mail-pj1-x1032.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1msER2-0000x2-F7 for emacs-orgmode@gnu.org; Tue, 30 Nov 2021 20:29:26 -0500 Received: by mail-pj1-x1032.google.com with SMTP id gt5so16701842pjb.1 for ; Tue, 30 Nov 2021 17:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=h8gPEI01/Bm4vOKoCrhkTzPKBB7+FnC0ZtYdLyCwB0I=; b=lJ5ridZqPhjmqYzaKVvj2vQ8sp/qfOA68o4IO5mJ0M4+qY84VrGhKkFRivFC+Qk/6m OKqJ5tpRSvI/pc4Y+r8+y9hq/EtOtmAlEWaL9Y6mo1+FpT24Hckuf87Py0vTaRp6u0u5 hqZzQqOH20zPdJhIXj58i4RPwDaopZNhTNOMvUiFCMMtEWvJBQAaV88RTg59Gij+oL47 abOTPFRxgaMx9pLiVMcuu/0eqNQq0JMz0mcgDolN6laNKClZmE4sVnMT3BjG/xu1W4o9 uODez27x8kK4MdQrd3Gd4QaFpdR1wpN/LdAOmr8wpQDDTGAAW3EoTiTWMBK7GWMInANF yG7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=h8gPEI01/Bm4vOKoCrhkTzPKBB7+FnC0ZtYdLyCwB0I=; b=K6tib/6++2D8IfOKPR/4bajG2rfhZTzeEl2HQwYJtH2dwtAxwam32lqLqEILN1kxAF 1MBQy8/sfnurlYFySCb0+qZ3Oc2Nn+X34pScyNR493i3VWBYeuaIwufm0vkUmDK6qiu9 4vIqN/cHGFi02zXKrQ5OoI0zdqRl/3iv6rwSpo+tGQiTL884J+jD9BENXlyu6vvv30+Z CWuC/PdR1dvGfzCo06LEaAzW34U/9McL8I8e5PoWjI02GNFEM025Zwwsf3EY5qIunMaH FkjcAAKgEq4nsVileHQfnhtcZE5PQAsi8NoNirc87bX22m7a36mlN61Qvp0uHEZhC/A9 Z+RA== X-Gm-Message-State: AOAM532Bl1JX+/F8eMgfiJxNJfwYaisV7bHCFcSRdYTkTc/S/wOGifyO vOzcm3X7tIbNcVPCYO+ONPLGUNGYjTE= X-Google-Smtp-Source: ABdhPJyXAlRT7RN4QBMwYjvTkuU53rwS4sJylgc97xOWn9jIV4MmTHZHTt/QLhgzn6lLG4NSg4ey1g== X-Received: by 2002:a17:903:1247:b0:143:b9b9:52a2 with SMTP id u7-20020a170903124700b00143b9b952a2mr3369688plh.35.1638322162664; Tue, 30 Nov 2021 17:29:22 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-a541-f132-a1f3-83b1.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:a541:f132:a1f3:83b1]) by smtp.gmail.com with ESMTPSA id e11sm3687478pjl.20.2021.11.30.17.29.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 17:29:22 -0800 (PST) References: <2021-11-28T20-44-37@devnull.Karl-Voit.at> <875ysb7v1r.fsf@gmail.com> <2021-11-29T14-12-55@devnull.Karl-Voit.at> <87tufuu8ah.fsf@atlantis> <2021-11-30T21-02-53@devnull.Karl-Voit.at> User-agent: mu4e 1.7.5; emacs 28.0.60 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode) Date: Wed, 01 Dec 2021 12:12:29 +1100 In-reply-to: Message-ID: <87pmqhi045.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1032 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1032; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1032.google.com X-Spam_score_int: -12 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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 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: , 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=1638322216; 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=h8gPEI01/Bm4vOKoCrhkTzPKBB7+FnC0ZtYdLyCwB0I=; b=TVHQxBdaOqm7DqKnCNcp5xqzK8nVB+CJp3z/ayVr6/H8Pz+VG1GTwkR6d2Qz/qiYGp6g3C doWR04X6GIbAWHJsd48dZOP/KhM1YMOJFLjtQLtdyhVb0qq+/tIdr8SdZhifZV8lD+ZFO+ BhmkK1/u1QIAWwP2SfzK/lxbPkdjBCCVXSEgGshP0iyX5dFKIgrEWhjZvH7BMTJwpejNdA 6Iy2bVKnagEby2qn2lRA7UzOjzP2KlUKGWsRy9as0kNriG2UPkgxqONUOU/woI9/0/k8q5 mlKeqLG8zvAwN/SN1sX+RRZ4SvBDy7OlpicImZpYJUcMTS7V9m/l9/JqZmowgw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638322216; a=rsa-sha256; cv=none; b=XLTxe8cek1RUDZOmVFKyVsfexZqVPStJblH9TnIrUegg6Rm/ETCbfDyjf2VK8NFdnIs3kp J1xAfReHP7rGuW31PjBoySIohPWBEAXLoHBuFoKs4FaY9s2sb8v1XcRO1qwJwAUge9xeku 0pUMt+hxQEL971Zn1zda+wIkIqKD6IVc7Gqfe5mqX9NDfaa3WUoYNmI3QVb6VpjrfPGQBA c/Iu5CdqX2wAZrYIx78sa4bN+71yYDQzbLfhZIF6IrACM+uIwyICQmxiol+QUdQgmGW+7T lYdMy6Uxbvr/Fv+vCviAgOdIb0xHQ0Mf+9zys6FXOjzrM8rpwmXe7JvtmzcxxA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lJ5ridZq; dmarc=pass (policy=none) header.from=gmail.com; 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: -4.11 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lJ5ridZq; dmarc=pass (policy=none) header.from=gmail.com; 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: 5D41A30E62 X-Spam-Score: -4.11 X-Migadu-Scanner: scn0.migadu.com X-TUID: GrUhmKMQ5BL5 Tom Gillespie writes: > Karl, > The exact naming of a thing is nearly always the most contentious > step in trying to promulgate it. In my own field we can easily get all > parties to agree on a definition, but they refuse to budge on a name. > As others have said, I wouldn't worry about kibitizing over the name. > > I would however worry about the larger negative reaction. From my > perspective I think the issue is that there are many efforts working > toward a formalized specification for Org syntax and Org mode > functionality, and some of those stakeholders who have invested > significant effort may feel blindsided by a public declaration > announcing Orgdown because they were not consulted and not > made aware that you were working on it. > > I appreciate the amount of work that you have put in, I have devoted > hundreds of hours to working on an alternate implementation of org > in Racket that uses a formal ebfn in hopes that others will be able > to use it as a guide and as a way to talk formally about how Org > parsers and implementations should behave. > > It would thus be easy for me to say that your approach has put the > cart before the horse, because there are countless nuances in the > specification for Org syntax which must be addressed before any > levels of org compliance can be specified, otherwise the behavior > between levels will be inconsistent. > > If I were to say this, it would not be fair to you at all. The ideas > and motivation for Orgdown are vital and important. You have put > in enormous thought and effort, all because you care about Org > and want to see it succeed. > > The issue is that any shared specification for Org syntax is > fundamentally about how to coordinate as a community. > The way that Orgdown was presented to the community feels > (to me) like it is being imposed top down or coming from an > individual source, not from an open and visible community > process (the subject of your original email reads as a declaration > in english, and thus can be quite off putting, though I know that > was not the intention). > > I personally haven't bothered with promulgation because I think > that we are not technically ready as a community to approach > outreach to other developers in a way that we can succeed. > > The good news is that all of this can co-exist if we want it to, > but we need to be clear about our objectives as a community. > > To me these objectives are as follows (and I would love > to hear from others about additional or alternate objectives). > > 1. To never fracture Org syntax so as to avoid the nightmare > of markdown flavors. (This means being able to say clearly > as a community that a parser is out of compliance and that > it is up to the user to fix their files. The ruby org parser used > by Github is a major issue here.) > 2. To provide a clear specification for what graceful degradation > looks like when parsing Org syntax if a parser does not support > some portion of that syntax (e.g. should property drawer lines > be excluded or rendered as plain text?). > 3. Provide a solid basis on which further formal specification > can be built. (My interests in particular are around providing > consistent semantics for org-babel blocks across languages > so that babel implementations can clearly communicate what > runtime features they support.) > > The approach for Orgdown can absolutely meet all three of > these objectives, however in its current form Orgdown1 is not > sufficiently well specified to avoid fracturing the syntax. > This is because Org syntax is extremely complex (even the > elisp implementation of Org mode is internally inconsistent) > and there are edge cases where behavior will diverge if parsing > of even the simplest elements is not fully specified. > > There are many ways to remedy this, however they require > a more formal approach. A number of us are working to build > technical foundations for such a formal approach, but I do not > think that any of those projects are ready to be used to > specify discrete levels of Org syntax parsing compliance. > > If I may, I would suggest that an Orgdown0 is something that > could be well specified, but it would avoid parsing of markup > altogether and only deal with the major element types. Parsing > paragraphs and all the org objects is not something that can > be done piecemeal. There are too many interactions between > different parts of the syntax, and in some cases the existing > specification desperately needs to be revisited due to the > complexity that it induces or because it is underspecified. > Of course this would make Orgdown0 fairly useless as a > replacement for markdown, but at least it would be a start. > Hi Tom, I pretty much agree with everything you wrote. I also feel it is unfortunate that Karl received so much negative focus on the name and not on the underlying idea - but I'm not surprised. As you say, naming is extremely hard and getting consensus is even harder. In hind-sight it would probably have been better to separate the two things - finding a name and defining a way to specify compliance. however, I also agree that I'm not sure we are yet ready to specify compliance because we need more formalism regarding what we are dealing with. One of the most important and I think potentially positive threads recently has been that of Ibor's regarding using the element parser to drive fontification and formatting. Inconsistencies between what an org file looks like and how it is parsed, exported etc seem to be the source for considerable confusion and bugs. Having the 'engine' be based around an element parser which all other components leverages from would at least provide increased consistency. Things will be easier to manage, fix and extend if they are consistent. I also think this is the key to being able to improve system performance and could provide a useful 'validator' which could be used by 3rd party tools to verify their implementations. It would also make extending org-mode easier. I also think less reliance on regular expressions scattered across different layers will make maintenance much easier. While regular expressions can be very powerful, they are hard to get right, maintain and avoid performance problems. I also find regexp in elisp one of the more difficult regexp formats/engines to work with.