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 kFlaG78Qn1+GLQAA0tVLHw (envelope-from ) for ; Sun, 01 Nov 2020 19:47:11 +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 oKxBF78Qn19cDAAAB5/wlQ (envelope-from ) for ; Sun, 01 Nov 2020 19:47:11 +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 EF9CB9402A0 for ; Sun, 1 Nov 2020 19:47:10 +0000 (UTC) Received: from localhost ([::1]:42616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZJJl-0000u1-EN for larch@yhetil.org; Sun, 01 Nov 2020 14:47:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47076) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZJJ0-0000tt-3P for emacs-orgmode@gnu.org; Sun, 01 Nov 2020 14:46:22 -0500 Received: from grinta.net ([109.74.203.128]:51248) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZJIw-0004ko-H9 for emacs-orgmode@gnu.org; Sun, 01 Nov 2020 14:46:21 -0500 Received: from black.local (unknown [193.148.18.84]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id C0A56ED9A1 for ; Sun, 1 Nov 2020 19:46:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1604259973; bh=gTQa7uW2t6Sfdvxrj3Hz3TsYyc6LEYE3VxJeM4HM63A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=e1MJfQr9Lw9qn/YdlCUSTvA8nuXnTQxt2QvPqyBVq5fsgfASqELRPGf4vVjBe0Fa3 WfYXGstJKD/q0iPtjOD/rn6Iw72sS2CjaVNxw4poqGaE9JrcjscY3eNF94PJvByqAA 308dWoskjrdsFiXozjEB5dexGRv7fRaI2tgwypPPUQlHZMVrj2f2KlcEvv4zlWlF9o LASuk/acd0EXmb2FC+3kNMzW5uHjxtJfKcI+5z+pPvjsITj/+lfl5M1LWzEKTBEAun ZNgvRlfQGXvWl4yBfV2cEVH613T4FEWaHpkMWc0JR30Cel9UCIPSMdmfzwmv6owdNs Ng4FCG9Wf4L9w== Subject: Re: Thoughts on the standardization of Org To: emacs-orgmode@gnu.org References: <20201101161317.GA6609@maokai> From: Daniele Nicolodi Message-ID: Date: Sun, 1 Nov 2020 20:46:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20201101161317.GA6609@maokai> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/01 14:46:13 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-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=fail (headers rsa verify failed) header.d=grinta.net header.s=2020 header.b=e1MJfQr9; dmarc=none; 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.01 X-TUID: tFfAfRwSnvGr On 01/11/2020 17:13, Russell Adams wrote: > On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote: >> First, I would like to repeat the importance of developing standards >> for org-mode. If we want to expand the influence of org, tooling must >> expand beyond Emacs. > > I disagree. There are other open text based formats outside of > Emacs. That Org is so compelling is because it's tightly integrated > into an Emacs mode which makes using Org data so easy. I cannot agree more with this statement and a similar statement (that I am too lazy to go search to provide correct authorship) that stated that 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. Reading the thread I have the impression that what wants to be standardized is the syntax of Org, but that is not very different from the syntax of other text based markup languages such at reStructuredText, asciidoc, Markdown, or others. What makes Org stand out, for some applications, is "org-mode" (as the implementation of Org in Emacs) and the tools built on top of the syntax. 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. If this is what you are after, I think a much more interesting goal (from the point of view of Emacs users and Org developers) would be to fold back some of the improvements org-mode builds on top of outline-mode back into outline-mode itself. This would immediately be beneficial as it would probably make Org simpler and the improvements could be actually be used by many. I also think that, if you are in the position to choose a format to use for collaborative projects, reStructuredText may be a better choice as the syntax is simple, well defined, and extensible. Although, without trying I don't know if outline-minor-mode can be made to work with reST-style sections headers. But, if it does not, it should not be hard to adjust it (see previous paragraph). Cheers, Dan