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 EEofJ1xRrWGNMAAAgWs5BA (envelope-from ) for ; Mon, 06 Dec 2021 00:55:08 +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 QM/hIlxRrWGwDQAA1q6Kng (envelope-from ) for ; Sun, 05 Dec 2021 23:55:08 +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 AC683320A3 for ; Mon, 6 Dec 2021 00:55:07 +0100 (CET) Received: from localhost ([::1]:40518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mu1LV-0007O0-Ga for larch@yhetil.org; Sun, 05 Dec 2021 18:55:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mu1Kz-0007Nl-8f for emacs-orgmode@gnu.org; Sun, 05 Dec 2021 18:54:33 -0500 Received: from [2607:f8b0:4864:20::631] (port=35730 helo=mail-pl1-x631.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mu1Kx-00023t-1F for emacs-orgmode@gnu.org; Sun, 05 Dec 2021 18:54:32 -0500 Received: by mail-pl1-x631.google.com with SMTP id b13so5945375plg.2 for ; Sun, 05 Dec 2021 15:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=IvT8BACx6IsJOPfaWjd/NjRcQZboQc4XH1W0pz1t0Uw=; b=R76SPnoBHYy9B7b52w0Fw+etB3htf2RGAZuNFSjOgeThkgauHNhSo2ND4ytgcVaNIb aF12olN6IcExzF+Fm2sWuCOtu6wG9xf+0mV2NDTKZLODlo9ZsDLZmHyWQmDYVNpk2Hua gJAacgxqROt6s5y7KWfgyJY6dTFZVrc+Qf5vNm4nhdY96KYEVHF9sh8UFO0/2cOH3tYf p7pWXwnGxMYvPBVRlkmeCnMm7ed+HHKJ0Fb0ahLUOnKXFmQnHD3f84JE9S53X8iy+XFl h2cnPh0+6UQd2xnpR7KTZFwY3gbGn841BJZiEb6bHCJnQnvUOf5udrv6UvqAoT4k49g4 Ih+Q== 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:cc:subject:date :in-reply-to:message-id:mime-version; bh=IvT8BACx6IsJOPfaWjd/NjRcQZboQc4XH1W0pz1t0Uw=; b=WObMkJS2nwKEYRIJi1gRfwk8/OESfWOC7yfRjvqkwz3LWE65W8gHEEOgwNKdU1BNIm co8ZFFQocM4pG0NDE3wXvx+rdMKc1sedVpgWDDvQBUqnRFzKlkEOoJLGiIfKWJw6JtGp ynOc1A9Q+NQwHDLpnJ/hP/Kg9TL2cKrulQcziU00rfZkrC2XnUD7V+pSVSQ8WGAZrgmR yy0GDuU50s8w5RJST7Dv47waLQxvQYVudQFrTUYaAH1gqyzUC2oRa4wz5SCy8ew+ECqv k4/azFEy0gkhgccobuMj0B0G2IT5+ipE3YdkxUpZLW1pr/QRhGIbYAMwkezlXaxtegJc jAeg== X-Gm-Message-State: AOAM531S9vq6aYYZFH+L3KBCqE3LQk9CKpNm/eGZzZl62uQmkmFefSjo yTjZtVB9iD51pFLEFmQ/vWJjVS3d0SY= X-Google-Smtp-Source: ABdhPJy27kDplfJcFe0xsGjVP7uShlvvWJH4Sx8x/vKW1ft+yg6/xH+Q8O1/RqKZtQ3jved+EF35sw== X-Received: by 2002:a17:902:ba84:b0:142:5514:8dd6 with SMTP id k4-20020a170902ba8400b0014255148dd6mr40176297pls.19.1638748469000; Sun, 05 Dec 2021 15:54:29 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-1567-b2de-f45a-a20e.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:1567:b2de:f45a:a20e]) by smtp.gmail.com with ESMTPSA id s14sm288144pfk.65.2021.12.05.15.54.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Dec 2021 15:54:28 -0800 (PST) References: <87tufnbj1w.fsf@localhost> <87sfv75s4r.fsf@posteo.net> <87o85vbb9a.fsf@localhost> <87y24zs40r.fsf@posteo.net> <87lf0zb6fq.fsf@localhost> <87ilw3419x.fsf@gmail.com> <87o85v9la3.fsf@localhost> User-agent: mu4e 1.7.5; emacs 28.0.90 From: Tim Cross To: Ihor Radchenko Subject: Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Date: Mon, 06 Dec 2021 09:39:33 +1100 In-reply-to: <87o85v9la3.fsf@localhost> Message-ID: <87a6he4ngu.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::631 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::631; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x631.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: , Cc: emacs-orgmode@gnu.org 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=1638748507; 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=IvT8BACx6IsJOPfaWjd/NjRcQZboQc4XH1W0pz1t0Uw=; b=ILdUzBwSm9o4AC603MH1D1ew/LQhtT3mGCTjdz1xdUNHWsebnMUHu8WM7WcW5JVHQFnXwH YuA7p9MoUPDnYVY+phqturjR07OLsyKXztDwEH7X4VWUwW1to8IUv8DhvUDcFLCQqr5Njd C0Z28+gwcIgJLftg75s647tFkYPyrUwgv6CTMrusmXviyqcCwdbzW0mHbyBBbrFSa6m1Ak 9Hj/1o1u0n4aUM9CM88+ytk8KNEmIfiEdYIsRydQ6EOv2maCMmHKRmM8eCKy4ZHH6IvcE8 bDwrARa4qK7u5+hP2m8JuBWcVKY9ehvj1ICoGONsDWno8n4PDg3bMngXH11TmA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638748507; a=rsa-sha256; cv=none; b=QWmrP4mhu95oaijITybkootPyiR0rlErj2yaZYMbEjpjlKp+SEm6a6RQHyBIorb9CHpmUy l9d9pEfezweWPj0PPrgX5LLoSqGrA76kB5RSXwnqzM7xiDbsE3RREYy/6Hrf4hI9zYRNjC LK11SIGfMuOK3XzDMjMnF0ISW4Maq6cm0Q61HhzNiHYXJbvPnCkK7D24E/1UDSwFRYxLGu s9ZQBEkna2Dlk9y5d/sJfg2zJRLYaDotfe+ms4mg26geedgLNK+y+MpsSM0/waZHo4bcKt /bHYpbuwv39EYYgJ4KkNn7PjC9tBLz/NcYj6Qd86nb7Ff0nI7TnkcfyxiCh4/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=R76SPnoB; 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.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=R76SPnoB; 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: AC683320A3 X-Spam-Score: -4.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: Oq+osxaOW7Cm Ihor Radchenko writes: > Tim Cross writes: > >> I think your working off a false premise. Your view is that org mode >> should be available in other editors/software so that others can realise >> the power and benefits it provides. I can understand that position. > > A clarification: my premise is that org mode should be available in > other _free_ editors/software. If we provide the means for other free > software to support Org mode (either as markup format or as some subset > of Elist implementation), it will benefit software freedom in general. > Whatever helper information (think of tests) we provide, it should be > licensed under GPLv3 with the following effect: > I don't disagree with this objective. My objection is to changing the emphasis or priority of org mode as an Emacs mode to a general technical specification for a small part of what is org-mode, the markup (I will outline the concerns I have in doing this below). The other point of course is that if you make it easier to implement org markdown in other editors, you don't have control over whether they are implemented in free or non-free solutions. > https://www.gnu.org/licenses/quick-guide-gplv3.html >>> It's always possible to use GPLed code to write software that >>> implements DRM. However, if someone does that with code protected by >>> GPLv3, section 3 says that the system will not count as an effective >>> technological "protection" measure. This means that if you break the >>> DRM, you'll be free to distribute your own software that does that, >>> and you won't be threatened by the DMCA or similar laws. > > The fact is that e.g. Github already provides support for Org markup. > They do it for their own profit and we cannot stop them. If we have a > controlled criteria about quality of third-party Org mode support, there > will be means to interfere with non-free software attempting to makes > profits out of Org mode. For example, if Github do not integrate our > recommended test suite (with all the legal consequences defined in > GPLv3), we will be able to have a list of third-party tools and, among > free alternatives, mention that Github support for Org is not verified > and most likely not consistent with other _free_ tools. We cannot do it > now. > There is a fatal flaw in this argument. The GPL licenses code, not the underlying idea (which is essentially what patents are about). We can define all the quality criteria we like for 3rd party implementations, but we cannot enforce them unless they are also using the GPL'd code. As this code is elisp, it is extremely unlikely any 3rd party implementation will be using it. In short, defining clear specifications and minimal quality criteria will only have baring on code added to org mode - it would, for example, have no effect on what github has/is implementing. >> However, the FSF position would be exactly the opposite. They would >> argue that orgmode is a powerful and flexible tool that is part of Emacs >> and if you want that power and flexibility, you need to use Emacs. Org >> mode has probably done more to bring new users to Emacs than any other >> Emacs mode in the last 30 years. As a consequence, you will find not >> only little support towards making it available in other editors, you >> are likely to run into active resistance. As you say, org-mode can be >> thought of as a brand name and that is a brand name owned by the FSF as >> an official GNU project and a goal of the FSF is to convert people to >> use GNU free software. Anything which has the potential to take the >> power of org mode and make it available in non-free software (not simply >> open source) is not going to be supported or welcomed. > > I am very much sceptical that third-party tools can provide the level of > Org support Emacs does provide. Emacs is and will remain the most > feature-full tool for people to use Org mode. Org mode's largest power > is configurability thanks to Emacs. On the other hand, Org mode's > support would be welcome in tools like TeXMacs or in forges like > Sourcehut (currently only supporting markdown). > I don't disagree about the benefit of org markup being supported in 3rd party tools. I disagree with the proposal to change the emphasis of the org-mode project from being an Emacs mode to being a more general technology. Consider this contrived scenario. We have adopted a change in emphasis to promote org mode as a more general solution and clarified the specification to make it easier for 3rd parties to implement. Meanwhile, Emacs development continues and new features/capabilities continue to be added. In particular, a new feature is added which is extremely powerful and would be a huge benefit for Emacs org-mode users. However, there is a problem. In order to take advantage of this new feature, significant changes are required for the specification. This will result in implementations requiring considerable work in order to update them to the new specification. Worse still, the nature of this change means that only Emacs org-mode users will benefit from this change. The change will not realise any benefit for 3rd party implementations. Now we have a problem. Either Emacs org mode users must give up on this great new feature or we break compatibility with 3rd party libraries. However, if the user base of the 3rd party implementations is much larger than the Emacs org mode user base, there will be strong pressure to not make this change. An extreme scenario to emphasise the point that moving org-mode from being primarily and Emacs mode to being a more general technical solution could easily have adverse impact on the development of org mode for Emacs users. I also have a more fundamental problem with the whole premise regarding org markdown and 'bringing it to the world'. This will likely be controversial, but .... There is nothing fundamentally better or more powerful about the markdown dialect used by org mode over any other markdown dialect. In fact, other markdown dialects are possibly even better than the one used by org mode. The power of org-mode is in all the non-markdown functionality - section folding, table formulas, executable source code blocks, powerful link definition facilities, noweb/literate programming support, planning/tasks/scheduling/time tracking, multiple back end target exports etc. To some extent, all these issues about markdown and compatibility in 3rd party libraries and editors is actually a consequence of org mode being defined at a point where markdown was relatively new and still somewhat immature. I see parallels here with much of the Emacs terminology which new users find very alien. The Emacs use of frames, windows and buffers or even the default key bindings for cut, copy and paste seem weird these days. However, they were novel new concepts when Emacs implemented them. It is similar with org markdown. At the time it was implemented, it was compatible with one of the best known and popular markdown dialects and one of the few to have actually written down it's specification. However, things evolved and now we have a handful of popular markdown dialects and the one org adopted is no longer as popular. If org had been developed later, it could well have adopted a different markdown syntax, possibly github flavoured for example. If this had occurred, we would have been more compatible with many 3rd party libraries and much of this debate would not exist. We have had many threads discussing how to increase compatibility of org mode in 3rd party applications and many good suggestions. Unfortunately, they usually amount to nothing because while ideas are cheap, action is not and often we get caught up on side issues which are not actually that important (at this stage at least). Forget about changing the emphasis or search engine results etc at this time. Focus on the more concrete components, like a clear specification of syntax, good unit tests and definitive reference documents. Just these three items represent a huge amount of work and all are likely prerequisites for establishing a vibrant 3rd party ecosystem. Worry about the rest later.