From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: William Rankin via "Emacs development discussions." Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re Org 9.4 is out. Can you help? // breaking apart Org Mode Date: Tue, 15 Sep 2020 20:05:20 +1000 Message-ID: Reply-To: William Rankin Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3264"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 27.1 To: emacs-orgmode@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 15 12:09:03 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kI7tX-0000jm-Hj for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 12:09:03 +0200 Original-Received: from localhost ([::1]:49644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kI7tW-0005KS-Kb for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 06:09:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44034) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI7rJ-0003tE-56 for emacs-devel@gnu.org; Tue, 15 Sep 2020 06:06:45 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:34546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI7rF-0007pS-Ga for emacs-devel@gnu.org; Tue, 15 Sep 2020 06:06:44 -0400 Feedback-ID: 791:353:null:purelymail Feedback-ID: 791:353:null:purelymail DKIM-Signature: a=rsa-sha256; b=GhhGGIHABcWz//Kj33CdMLveqFIDLt8DjGwNbRNU+exYaWO+coy7/6dX/M9GRLJxZUlbOvwCOpVu9h+uF9CKfluohEe0a21NoAX9u+/+nzuQnYMpLFJZoxaPKmIfs4xCoHHeAopnzT7+c3NlAbzfu6jD9JlVlyIhlUDowMDexniuRNwn+mIYvWEBKBP5awbZ2xKMqZd2fwUnD+pvVgKb3Oy/0OfbIprijehUIesgpxw0piNeapGtQ4NSzPm40WWaQw8jIwCXuL2CrfIU5p7G/kTdQYy98pzAFxy33MuGBbQqHlUx6G3W/aP/cGK4sOOJECZ+sKNRGQw14gdHfYkkdA==; s=purelymail1; d=bydasein.com; v=1; bh=C3Do72METwLJP6iurRJIpWf/Ns4/2uwq0yt8tUpqcOA=; h=Received:From:To; DKIM-Signature: a=rsa-sha256; b=AgMDyo1awDTKdHP/UEzGDIXX4cnftQZbhr/bVnrtMMrr2XmARIv/78DS80SSfQppeBeaziSBcmafRd5iDeTYL4TZ+G2GkvUwWrqzZfFMGxtW8EvueMbiGlSF9IphI9djEdx1D+bnpVqXl3tRaJa8JmyROWLOiBaldeY+yBNh03/vNPbFSfqA5sWAjINd6nmNCp1qhl5+lDV5NHlFsSjED3C5gVKjLMgPZw4iyhnS6bjuVYlX2aMB2h0Mu8IRL3oUCmiuY1Ixc3M/BKPsIaTXDsiwG0c700+bCwns6lsXUZYCD1C7VwWN6EPZ+sRvMX+5ezFbHHvVK3cWl9gAKzlsIA==; s=purelymail1; d=purelymail.com; v=1; bh=C3Do72METwLJP6iurRJIpWf/Ns4/2uwq0yt8tUpqcOA=; h=Received:From:To; X-Pm-Original-To: emacs-devel@gnu.org Original-Received: from 120.22.115.136 (EHLO localhost) ([120.22.115.136]) by ip-172-30-0-247.ec2.internal (JAMES SMTP Server ) with ESMTPA ID -262375745; Tue, 15 Sep 2020 10:05:28 +0000 (UTC) Received-SPF: pass client-ip=34.202.193.197; envelope-from=william@bydasein.com; helo=sendmail.purelymail.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/15 06:05:38 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:255727 gmane.emacs.orgmode:131534 Archived-At: Hello, At the request of Bastien I'm sending on these ideas regarding the future of Org Mode development. I'm also copying emacs-devel since they might be interested too. Org Mode and Emacs would benefit greatly from the codebase being broken apart, not unlike how an antitrust suit breaks apart a big company for the good of society! It is my view that many parts of Org code could be implemented as minor modes or independent libraries. This would encourage cleaner, more modular and more easy to understand code. It would provide an exponential benefit for other elisp programs. And by splitting up the codebase you allow contributors more a sense of ownership and emotional investment in the things to which they provide their time/effort. A few suggestions... * outline Org Mode builds on top of outline, but those improvements are isolated to Org, e.g. Org has wonderful outline cycling, but if someone wants outline cycling in another major mode they need to implement this again (likely just duplicating Org's existing code). Ideally all of this could be ported back to outline itself. This would slim down the Org codebase while benefiting all other outline-based major modes. * orgtbl-mode This is a good attempt at implementing some of Org's functionality as a minor mode. Ideally orgtbl could be ported back to table and enough flexibility added to make it compatible with Markdown Mode tables (currently implemented with its own table stuff). * source blocks Org's source block functionality could be spun off into its own library. In theory it could work just like outline (where a major mode defines its own heading regexp). A major mode would define its own source block delimiter regexpes. Ideally any major mode writing for a plain text markup format would just: (require 'source-blocks) then have all the same functionality of Org source blocks. Any improvements would then benefit everyone. * org-toggle-time-stamp-overlays / org-toggle-link-display This functionality, although small within Org, could be very nice as their own minor modes. Displaying dates/times with custom format is easy enough... URLs a bit harder. I went so far as to try this with varying degrees of success: https://github.com/rnkn/prettify-date-time-mode https://github.com/rnkn/prettify-url-mode * org-link I see a lot of interest for that Zettelkasten method, with many different implementations. What's stopping Org's cross-linking being implemented as its own global minor mode, independent of .org files? * electric-pair-mode Org currently uses org-emphasize for its emphasis pairs, but could it just use electric-pair-mode? Would this prompt some improvements to electric-pair-mode? This would benefit everyone. I don't mean to suggest that the above ideas are things I'm particularly hanging out for, I'm just trying to sketch an ideas of beneficial ways Org could be broken apart. Finally, I'm pretty sure breaking apart Org will mean it will be much easier to maintain -- it will be far easier to find one or two people passionate about maintaining perhaps a source-blocks library than the entirety of Org. If Org's development takes this more modular direction, where libraries are designed to work independently of the rest of the code, then it won't need an elite few people who understand the whole codebase. I hope some of these ideas were either valuable or provide valuable discussion. -- William Rankin https://bydasein.com ~ The single best thing you can do for the world is to delete your social media accounts. 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 yG7eAx2VYF9oCAAA0tVLHw (envelope-from ) for ; Tue, 15 Sep 2020 10:19:09 +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 aNyuORyVYF/gCAAAbx9fmQ (envelope-from ) for ; Tue, 15 Sep 2020 10:19: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 9169594053F for ; Tue, 15 Sep 2020 10:19:08 +0000 (UTC) Received: from localhost ([::1]:34136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kI83H-0002f6-H7 for larch@yhetil.org; Tue, 15 Sep 2020 06:19:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI7rF-0003rP-6N for emacs-orgmode@gnu.org; Tue, 15 Sep 2020 06:06:41 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:34470) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI7qH-0007ga-FF for emacs-orgmode@gnu.org; Tue, 15 Sep 2020 06:06:40 -0400 MIME-Version: 1.0 Feedback-ID: 791:353:null:purelymail Feedback-ID: 791:353:null:purelymail DKIM-Signature: a=rsa-sha256; b=GhhGGIHABcWz//Kj33CdMLveqFIDLt8DjGwNbRNU+exYaWO+coy7/6dX/M9GRLJxZUlbOvwCOpVu9h+uF9CKfluohEe0a21NoAX9u+/+nzuQnYMpLFJZoxaPKmIfs4xCoHHeAopnzT7+c3NlAbzfu6jD9JlVlyIhlUDowMDexniuRNwn+mIYvWEBKBP5awbZ2xKMqZd2fwUnD+pvVgKb3Oy/0OfbIprijehUIesgpxw0piNeapGtQ4NSzPm40WWaQw8jIwCXuL2CrfIU5p7G/kTdQYy98pzAFxy33MuGBbQqHlUx6G3W/aP/cGK4sOOJECZ+sKNRGQw14gdHfYkkdA==; s=purelymail1; d=bydasein.com; v=1; bh=C3Do72METwLJP6iurRJIpWf/Ns4/2uwq0yt8tUpqcOA=; h=Received:From:To; DKIM-Signature: a=rsa-sha256; b=AgMDyo1awDTKdHP/UEzGDIXX4cnftQZbhr/bVnrtMMrr2XmARIv/78DS80SSfQppeBeaziSBcmafRd5iDeTYL4TZ+G2GkvUwWrqzZfFMGxtW8EvueMbiGlSF9IphI9djEdx1D+bnpVqXl3tRaJa8JmyROWLOiBaldeY+yBNh03/vNPbFSfqA5sWAjINd6nmNCp1qhl5+lDV5NHlFsSjED3C5gVKjLMgPZw4iyhnS6bjuVYlX2aMB2h0Mu8IRL3oUCmiuY1Ixc3M/BKPsIaTXDsiwG0c700+bCwns6lsXUZYCD1C7VwWN6EPZ+sRvMX+5ezFbHHvVK3cWl9gAKzlsIA==; s=purelymail1; d=purelymail.com; v=1; bh=C3Do72METwLJP6iurRJIpWf/Ns4/2uwq0yt8tUpqcOA=; h=Received:From:To; X-Pm-Original-To: emacs-orgmode@gnu.org Received: from 120.22.115.136 (EHLO localhost) ([120.22.115.136]) by ip-172-30-0-247.ec2.internal (JAMES SMTP Server ) with ESMTPA ID -262375745; Tue, 15 Sep 2020 10:05:28 +0000 (UTC) User-agent: mu4e 1.4.13; emacs 27.1 To: emacs-orgmode@gnu.org, emacs-devel@gnu.org Subject: Re Org 9.4 is out. Can you help? // breaking apart Org Mode Date: Tue, 15 Sep 2020 20:05:20 +1000 Message-ID: Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=34.202.193.197; envelope-from=william@bydasein.com; helo=sendmail.purelymail.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/15 06:05:38 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 15 Sep 2020 06:18:17 -0400 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" Reply-to: William Rankin From: William Rankin via "General discussions about Org-mode." X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=bydasein.com header.s=purelymail1 header.b=GhhGGIHA; dkim=fail (rsa verify failed) header.d=purelymail.com header.s=purelymail1 header.b=AgMDyo1a; 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: HTS4rp9Xvm0d Hello, At the request of Bastien I'm sending on these ideas regarding the future of Org Mode development. I'm also copying emacs-devel since they might be interested too. Org Mode and Emacs would benefit greatly from the codebase being broken apart, not unlike how an antitrust suit breaks apart a big company for the good of society! It is my view that many parts of Org code could be implemented as minor modes or independent libraries. This would encourage cleaner, more modular and more easy to understand code. It would provide an exponential benefit for other elisp programs. And by splitting up the codebase you allow contributors more a sense of ownership and emotional investment in the things to which they provide their time/effort. A few suggestions... * outline Org Mode builds on top of outline, but those improvements are isolated to Org, e.g. Org has wonderful outline cycling, but if someone wants outline cycling in another major mode they need to implement this again (likely just duplicating Org's existing code). Ideally all of this could be ported back to outline itself. This would slim down the Org codebase while benefiting all other outline-based major modes. * orgtbl-mode This is a good attempt at implementing some of Org's functionality as a minor mode. Ideally orgtbl could be ported back to table and enough flexibility added to make it compatible with Markdown Mode tables (currently implemented with its own table stuff). * source blocks Org's source block functionality could be spun off into its own library. In theory it could work just like outline (where a major mode defines its own heading regexp). A major mode would define its own source block delimiter regexpes. Ideally any major mode writing for a plain text markup format would just: (require 'source-blocks) then have all the same functionality of Org source blocks. Any improvements would then benefit everyone. * org-toggle-time-stamp-overlays / org-toggle-link-display This functionality, although small within Org, could be very nice as their own minor modes. Displaying dates/times with custom format is easy enough... URLs a bit harder. I went so far as to try this with varying degrees of success: https://github.com/rnkn/prettify-date-time-mode https://github.com/rnkn/prettify-url-mode * org-link I see a lot of interest for that Zettelkasten method, with many different implementations. What's stopping Org's cross-linking being implemented as its own global minor mode, independent of .org files? * electric-pair-mode Org currently uses org-emphasize for its emphasis pairs, but could it just use electric-pair-mode? Would this prompt some improvements to electric-pair-mode? This would benefit everyone. I don't mean to suggest that the above ideas are things I'm particularly hanging out for, I'm just trying to sketch an ideas of beneficial ways Org could be broken apart. Finally, I'm pretty sure breaking apart Org will mean it will be much easier to maintain -- it will be far easier to find one or two people passionate about maintaining perhaps a source-blocks library than the entirety of Org. If Org's development takes this more modular direction, where libraries are designed to work independently of the rest of the code, then it won't need an elite few people who understand the whole codebase. I hope some of these ideas were either valuable or provide valuable discussion. -- William Rankin https://bydasein.com ~ The single best thing you can do for the world is to delete your social media accounts.