From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id YF40F0/aoV/XCwAA0tVLHw (envelope-from ) for ; Tue, 03 Nov 2020 22:31:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id eILyEk/aoV9zXAAAbx9fmQ (envelope-from ) for ; Tue, 03 Nov 2020 22:31:43 +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 BC7E194021E for ; Tue, 3 Nov 2020 22:31:42 +0000 (UTC) Received: from localhost ([::1]:55046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka4q3-0000Fv-TI for larch@yhetil.org; Tue, 03 Nov 2020 17:31:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ka4os-0000E4-BC for emacs-orgmode@gnu.org; Tue, 03 Nov 2020 17:30:26 -0500 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]:39729) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ka4oq-0006UM-AE for emacs-orgmode@gnu.org; Tue, 03 Nov 2020 17:30:26 -0500 Received: by mail-il1-x136.google.com with SMTP id q1so17613234ilt.6 for ; Tue, 03 Nov 2020 14:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2As1rgqmpTBdF2hzSzMbUGyefcMCItvgDWQ3z/mZO3Q=; b=WFusIs4TTb6ToHY/nKRpq+VC0rtxUbKDI2J5KjxU400OONfkpWoRw8wN6gHlo/zyy/ 0ILfN/n36qS8lkyyxHo1yaPOuNWOPBU8eqzSxFStEelfG2nULN5uz2HJk3bYHsnmhc5I AqpXY2ugn5NlZR4iREuOX8KFDxG2r2MzhsxJZEeSWzGyDRbT4CfJ0DqIF5onvLOvtOd+ ppkyySe/z2uiSvD4v0IAesmwZJonfHAnkE6KcWO76jpNQQJElP3pwbsA9Px1CIkRXc0Q q45TznUCO9aVN090gLqCeQg19RmxhUmlTEP5ZNTzxK7GtwXTqS3g+KZMHVhN12ni4x6c qMJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2As1rgqmpTBdF2hzSzMbUGyefcMCItvgDWQ3z/mZO3Q=; b=p3ELUwhD5d1tLGL7wbPza2tSzMNGKebM7Otu43hGQyjkyz5OEK79zgQOwUEwc8BDzB Y1Cf1MRi8gaEa5biopgr2c6dAETZdcf5HbWaBGbFQtGTbHx9E17STV6KvbpQFZWm01+s hvQ6VS2G2zwy1mCu6egEnnKdUOCwkXtdrOtDnYfuzhQKTQdFK9rX57cRdNIbggAeCFAV cUIjzA49gYXAfPwCuj7K8CuuBFBJKPy+Qyb8NLGBkYvVl5sK4XuA4cwbJ+R5a0CVW3ts D7VBN4FbQYaiN3nA04up/AXTd9iTmZ0Ga2ANHai5ukIdHjmPQgxPrYGmDLwDMBQuJjt/ SogA== X-Gm-Message-State: AOAM532JXVbaDnS3BN1mpMZcn4BFVKklWaFL/hH7W13IQaZZAYMEJEGf uAvFYCBILZ/V39m0hTusxVKCxUnLn6KKq4N2Qdg4OBQbcPPw2w== X-Google-Smtp-Source: ABdhPJz+DlmxT0bu+a+gGuZltJefqhDF6rH0Qa0PcnOChjpgpq+zyCiIl8KzD4Dwh4OtyskdogygSHYe3k1raOqUpaM= X-Received: by 2002:a92:c84e:: with SMTP id b14mr16495659ilq.295.1604442622337; Tue, 03 Nov 2020 14:30:22 -0800 (PST) MIME-Version: 1.0 From: Asa Zeren Date: Tue, 3 Nov 2020 17:30:12 -0500 Message-ID: Subject: Re: Thoughts on the standardization of Org To: emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::136; envelope-from=asaizeren@gmail.com; helo=mail-il1-x136.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=WFusIs4T; 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: -0.71 X-TUID: 6hJ42scktiI/ I have collected below some quotations to try to represent the general sentiments expressed so far in the conversation, upon which I would like to express some thoughts. Most of these have been repeated several times in spirit, so they are not just the opinions of the listed authors. Daniele Nicolodi said: > I don't think it is reasonable to expect much of org-mode being implemented in > another environment, because that quickly becomes a task as complex as > implementing Emacs. For example, Org has org-tables, and the formula syntax > allows for Emacs Calc expressions or Elisp functions to be called: should an > hypothetical implementation of Org allow the same formulas to be executed? > Wouldn't that mean that this implementation needs to re-implement a good > fraction of Emacs (or use Emacs itself for interpreting the formulas? > > Maybe the standardization should cover only the "static" parts of Org (IE no > table formulas, no babel, no agenda, no exporters, etc). However, in this > case, what is left is little more of a markup language with an editor that > allows sections folding. You can have this on top of pretty much any markup > language using Emacs' outline-minor-mode. Daniele Nicolodi said: > one of the advantages of Org is that, being implemented in Emacs, it has > infinite potential for customization, thus we would need to agree about what > org mode is before standardizing it: my Org is not your org, and, thank to the > features offered be the Emacs environment, I use different flavors of Org in > different buffers. I 100% agree that much of the power of org mode comes from the infinite customization. However, I do not agree that this fact makes standardization impossible (see below). Additionally, Emacs is not the only customizable tool, though it is a very good one. The org standard would have to be flexible to accommodate that "my org is not your org," but this is not impossible. Ken Mankoff said: > Therefore, if other tools have the ability to do *something* with an Org file > (display most of it well enough, allow editing without breaking things, maybe > implementing a simple Babel interpreter for a few popular languages, > whatever), this would be A Good Thing. TEC said: > I also think it's to our benefit that non-Emacsers become more comfortable > with seeing an org file --- as I see it that improves our chances that we can > directly share Org files with them, which they might be comfortable editing > and sending back for example, or that a generic tool might think to support > Org files. These points are especially important, and while a standard is not the only way to progress these goals, it is a good step. Also, re the MIME type discussion, while there was a long list of steps that need to occur for a MIME registration to be useful, I would like to point out that a standard is the first step towards that goal, and even though there are more steps, many of them difficult, that does not mean that we should not make progress. Greg Minshall > perhaps the standard for e-mail headers (originally, RFC822) might be a useful > way of thinking about this issue. it standardizes what it standardizes, and > then says, "and, by the way, you can put in almost anything else [X-Mailer, > ...], but you can't count on any other node understanding it". over time, new > things are standardized (and, so, moved to, e.g., Mailer, and other things > aren't. > > it seems to me this has worked fairly well, and partly this works because of > the late Jon Postel's admonition for designing internet protocols: be > conservative in what you send, and liberal in what you accept. This is a good precedent for how I would like to standardize org. First, standardize general structure, without the specifics. Then, as ideas around a particular feature stabilize, they can be separately standardized, and incrementally adopted. (Though likely many major implementations (aka Emacs) would have already implemented it, even though it is non standard.) For more details on how I think this should be accomplished, see my original post, and also this reply for clarification: https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00009.html Ken Mankoff said: > The conversation should move from "it can't be done" or "it isn't helpful" > (why so much negativity on this thread?) to > > + What parts can be standardized and re-implemented outside of Emacs. > + How do we define graceful failure for the other parts. > + How do we support 3rd-party implementation in a way that benefits all of us. This post I also find especially important. There seem to be the ideas that (a) an incomplete implementation is not useful and (b) a standard would necessarily either require another implementation to implement all of Emacs or would eliminate the customizability of org. Thanks, Asa