From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bastien Newsgroups: gmane.emacs.devel Subject: Re: Org mode and Emacs Date: Sun, 25 Sep 2022 08:35:54 +0200 Organization: GNU Message-ID: <8735cgot9x.fsf@gnu.org> References: <87y1u8b1gj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11853"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Payas Relekar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 25 08:37:44 2022 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 1ocLGp-0002w3-Fk for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Sep 2022 08:37:43 +0200 Original-Received: from localhost ([::1]:51160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocLGo-0005x2-1O for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Sep 2022 02:37:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLFD-00057k-W1 for emacs-devel@gnu.org; Sun, 25 Sep 2022 02:36:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49838) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLF7-0007ce-SY; Sun, 25 Sep 2022 02:36:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=JuXpyQDLG8k27mHH3PA00u2RX6Rym7ldjY62f9Kseg8=; b=pQN+Wc/NNVyWbSRfOipp 02w3pNiqjwLJIwEtwxckZZc4+TwObJIDfXJCjQJ4Mw5O4BORTxqkl567Xx+nB6JXdCLMRDHr0cCef Dd2fx24tjYRweZnDYxHucIbYa/csulbYB+/sONv9AiAKAHMBlilaHhjskg0RH2pt3RYRmAGFRIUSo u3VfviGUKTMlbbLIzmBjWVCkjhro2+/gmJlEGigmVzeQDVxcW1J01tPzAWzJuZ61mQ+BE2HnQXT8j X8U12KVsUmTbYhXH/xg3wDqUXOeBaVpmKoFf0e4a4DZDILu1ea63m8sfk+F2uIH48xNFMCyMz/5e2 ymcr221jEEF74A==; Original-Received: from 96.52.140.77.rev.sfr.net ([77.140.52.96]:37108 helo=hal) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLF7-0002Lq-IH; Sun, 25 Sep 2022 02:35:57 -0400 Original-Received: by hal (Postfix, from userid 1000) id BEBF31E0409; Sun, 25 Sep 2022 08:35:54 +0200 (CEST) In-Reply-To: <87y1u8b1gj.fsf@gmail.com> (Payas Relekar's message of "Sun, 25 Sep 2022 08:22:03 +0530") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:296198 Archived-At: Hi Payas, Payas Relekar writes: > From your mail, below were the motivators for change: Re-reading it, the list was a mix of (1) things to be done for the switch to be sensible (and that will be boosted if the switch happens) and (2) possible nice outcomes. > - Let's stabilize editing standards around the org.org file. (=> 1) Something that we did before the switch. > - Let's test org capabilities against a giant .org file. (=> 2) Yes, this can lead to enhancements in Org like it did recently, but I don't think this is a good reason enough to justify the switch. > - Let's make `C-x 4 a' do something useful in an .org section. (=> 1) Also something now available. > - Let's write more non-emacs parsers and exporters. (=> 2) This was an illusion: I don't think projects like Pandoc use the org-manual.org file to test whether they are good parsers and exporters. For a good reason: nobody really needs to use Pandoc for parsing/exporting the Org manual. > - Let's see if we have more contributions to the manual and if > we really solved a problem here. (=> 2) This didn't happen. > While you're best to judge the number of contributions, #1 and #2, or > the dogfooding opportunities provided by the switch are immense. > > One doesn't occasionally run into org documents the size of org.org. It > has already resulted in gc enhancements as it was slowing down Emacs > build and was optimized. I'll say that alone is a benefit worth keeping. I'm not convinced: slowing down Emacs build to create opportunities for enhancing the Org parser and exporter does not strike me as a good reason. Respecting the GNU standards about manuals ("The preferred document format for the GNU system is the Texinfo formatting language.") and the recent discussions provide good reasons for switching back to .texi, if all maintainers agree. > There is also more progress being made on non-emacs parsers[0][1], and > perhaps we can reach out if they find org.org useful. Generally > speaking, these projects are even smaller (number of contributors-wise) > than org-mode, but a shared burden is always nicer. > > [0]: https://github.com/nvim-orgmode/orgmode > [1]: https://github.com/200ok-ch/org-parser/blob/master/resources/org.ebnf Of course, feel free to contact them, but why would they want to try solving the challenge for exporting org-manual.org? They can create any .org file with the complexity they desire if they need it. Also, independently from this discussion, _we_ should certainly provide an example document containing alls things a parser/exporter should be able to handle. All best, -- Bastien