From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kakzOuGCoF8YAwAA0tVLHw (envelope-from ) for ; Mon, 02 Nov 2020 22:06:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id oOCoNeGCoF/GTgAAB5/wlQ (envelope-from ) for ; Mon, 02 Nov 2020 22:06:25 +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 112E59403C4 for ; Mon, 2 Nov 2020 22:06:25 +0000 (UTC) Received: from localhost ([::1]:52974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZhy3-0005ak-SF for larch@yhetil.org; Mon, 02 Nov 2020 17:06:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZhx6-0005Zb-Eb for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 17:05:24 -0500 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:41209) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZhx2-0000Th-5x for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 17:05:24 -0500 Received: by mail-pl1-x629.google.com with SMTP id w11so7526623pll.8 for ; Mon, 02 Nov 2020 14:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=buHDhXN/liQUEBge4iQIt7aIcFM0bDkFohuwP0V+0ho=; b=nXdF148k1y/g8L1Y/fXinj+go9n4FjAwEpxofQDFtIhLHsg1QbZHythuojzp3QsPm0 C7STGQT1sGmTy+QzmI2WVjwMCCW3J7+8U1rEtwjEQuv2T7F95qha8ZJbjJ7Xytt/dTcS DrodDEAkhAG556wBZgpP8WOCWuNoFWf0Czw3r3Rgadln4sBZDobliSuNFK1JL3UP3BJx KB2Dq7qTf2mpi/gBAi23g/AeuV5ZePn8LF4YrqIH8FLT2NMs1/lM+KbhJs6RE+44QmNc ea2G6RzrnW8zxikI/rJDcr5eTtTUcIbvZnaFw6f/etOl5YRnR1VLRLBVtooaqppb7vmG y7kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version; bh=buHDhXN/liQUEBge4iQIt7aIcFM0bDkFohuwP0V+0ho=; b=QywBOZceSesri1nG5F9wdgHHuv/oOUVZt+uMT9RpE9bYuPW8rpbkD/y/tGK9wsoWUg x7NLPXQspbmX8IGK34N517NwQQ01s/RlXrPXtpbJUKAvut73dK2ZLhmTU6BTuxcWSBuZ 5O5FYR827NcJ1nrPgtxWoF6PASKuU+i0Mc0EUeAvk198xePGjkD0Wn3WwdxXbcmZsrJo kDdZPF20K6ereGcozoNkhOXuNgafyxyqDzsmVV5CBVi6TNsOto1+aW11QOQlFSJwRRg3 EDCg4VhI++almeW/S21o9pEZ5TPCFK5nzrNbo/z7VN2uGXuDuz8Y7++21A58JJgH1G3n BZ0A== X-Gm-Message-State: AOAM53285hvpwfO7qN8nhA1Ebk+NLPNLpIOEXYaz6ez5G7muBbAmUW7i /6NAmTdANqqaFl5D86S8IhGXRqrtaXTHmg== X-Google-Smtp-Source: ABdhPJzqn7VFKntmv4DuoN8D9sdMpEdgg3pEoo8f06EnjY/mgenCiCT6O8uWhSmvR2+LqRsq3RM+iA== X-Received: by 2002:a17:902:8215:b029:d5:f299:8b11 with SMTP id x21-20020a1709028215b02900d5f2998b11mr22616209pln.39.1604354717465; Mon, 02 Nov 2020 14:05:17 -0800 (PST) Received: from tim-desktop (106-69-133-156.dyn.iinet.net.au. [106.69.133.156]) by smtp.gmail.com with ESMTPSA id 34sm11921574pgv.53.2020.11.02.14.05.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Nov 2020 14:05:16 -0800 (PST) References: <1187707.1604326959@apollo2.minshall.org> <87mtzz958l.fsf@ucl.ac.uk> User-agent: mu4e 1.5.6; emacs 27.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Thoughts on the standardization of Org In-reply-to: <87mtzz958l.fsf@ucl.ac.uk> Message-ID: <87lffjv2hz.fsf@gmail.com> Date: Tue, 03 Nov 2020 09:05:12 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x629.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, RCVD_IN_DNSWL_NONE=-0.0001, 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-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=nXdF148k; dmarc=pass (policy=none) header.from=gmail.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-Spam-Score: -1.71 X-TUID: o8zwsYakv/+j Eric S Fraga writes: > > A more subtle issue, and one that I raised earlier, is the underlying > infinite customization provided by Emacs. Some of my macros are elisp > code. A standard for the structure of org mode documents could exist > but using such standard-compliant documents would be shackled by not > having elisp available to process the macros. They would really only be > usable within Emacs and hence my suggestion that what people really > want, without knowing it, is Emacs everywhere. ;-) [1] > I think the above is perhaps the most critical point. Much of the talk on standardisation seems to be focusing on org's markup layer. This is only a small part of org. Many of my org documents include macros, results from code block evaluation and rely on elisp code execution when certain content changes (such as changing a todo status). Without any of this, the document is not an accurate representation compared to how it is when viewed/used within Emacs. Even the goal of collaborative editing won't work because changing the data outside Emacs won't trigger the macros, functions, code blocks etc to update dependent parts (e.g. changing the TODO status won't result in the timestamp I record in the draw from being updated or updating that value in a table wo't result in re-calculation on formulas etc). One suggested benefit for standardisation was in being able to add a MIME type. Like others have mentioned, I'm unclear on how exactly adding a mime type really helps anyone. Having a MIME type only gives value if you can also have a MIME handler. Nobody except Emacs users have a MIME handler for *.org files and if you are an Emacs user, then Emacs will handle that type based on the built-in type handlers. Even if you had a very basic org parser, about all you might get is some syntax highlighting and maybe some folding support. You are unlikely to have much editing support (for example, you won't know from just the file what the defined keywords are, only the keywords used, same with tags, priorities, etc). People have mentioned that github and other systems support org mode files. I think this is a little misleading - they support a subset of the org-mode markup and can add minimal text highlighting based on that markup. These implementations all seem only partially complete and tend to only handle highlighting for more common languages. While it is great they have this support, to view this as proof of a the viability of an external non-Emacs org-mode is perhaps a little optimistic. The term 'standardisation' might have been a little misleading for this discussion. Much of what people seem to be talking about could be satisfied with a completed syntax reference like the one on worg. This would be sufficient to allow development of systems that are able to parse an org file and render it in specific formats (like github does). Perhaps focusing on how to make this document as clear and complete as possible would be a better effort than trying to define some formal specification of the whole org-mode system.