From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Org mode and Emacs (was: Convert README.org to plain text README while installing package) Date: Mon, 13 Jun 2022 08:56:54 +1000 Message-ID: <877d5lwhbg.fsf@gmail.com> References: <871qw31ois.fsf@yahoo.com> <8735gj4ceo.fsf@gnu.org> <87ee038ipt.fsf@gmx.de> <87o7z61v59.fsf@gmail.com> <87bkv527p5.fsf@gmail.com> <835yld93w7.fsf@gnu.org> <877d5t0yrn.fsf@gmail.com> <87r140yuof.fsf@gmail.com> <875yl9e7zm.fsf@gmail.com> <83czfh12kp.fsf@gnu.org> <87pmjhghu2.fsf@localhost> <835yl910gp.fsf@gnu.org> <87wndndbhq.fsf@gmail.com> <874k0qbrhe.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.27; emacs 28.1.50 Cc: Ihor Radchenko , eliz@gnu.org, monnier@iro.umontreal.ca, acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 13 02:15:01 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 1o0XjQ-000514-Md for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Jun 2022 02:15:00 +0200 Original-Received: from localhost ([::1]:42562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o0XjP-0004uZ-4d for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Jun 2022 20:14:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o0XiW-0004Fe-Oy for emacs-devel@gnu.org; Sun, 12 Jun 2022 20:14:04 -0400 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:51981) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o0XiU-0001Vv-Ee; Sun, 12 Jun 2022 20:14:04 -0400 Original-Received: by mail-pj1-x1030.google.com with SMTP id cx11so4215377pjb.1; Sun, 12 Jun 2022 17:14:01 -0700 (PDT) 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=oQhTefToHg2Xth5LuPvNL3Mevifmm94ElaMPifoIy64=; b=nSGzyTx24bDo/KpxXj8e/iyK5920Fv/XGQ3fmpYpbVdSHbdb/uaViHD/J6YvKsl83W vLKcMiq9xZkSepXuIOhL71JC+6VutocyrOFQXAjkh2DPTiEeFxAJE33xDatJRkuDaRJ0 X49u/1VPosWP1HUXdA7FZJrS4rBALhoIdQmLoT9aLKIi+Ars+HpXnwH4FY77Y2IReuDX MeedyXd5UeW9YJGKs7fB4gY+Q29YdqoES8VXgirWK/eFvayZaHRzj70aVQcvP8Wgf7aF xb9pO6cD7ZRv4nHb58pLOQKxoS9MXkBYEeNVyQXxZc7zmnknUZrmIMpprBbUY+Kj7OKp +qRg== 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=oQhTefToHg2Xth5LuPvNL3Mevifmm94ElaMPifoIy64=; b=KPjvpRjnqUYdmW3DXFO+WLBVhCqSNxaSoDFNzTIXVar6lt2i9sqkyzJJsNLlFIeLNl c0V7TM5sBYtX6W72Hhl5MorrlmfI8nbA4SnHiorSz/EWPxAvchnkhg0ceabllmyMtcET Onh0CdRiKzpd9Kr8EFgfJ3qNtmwmSucY35BRQFQhoUWkhS2j5nj04T0uL1D836QZ9YB4 ALVvVMz9JCNgiGtCdgBBEDfxB9gSzc6YGdn6pd9vkL06Zqpwkdpxq/cnS0+RA8ZY2H8N 0eXaWYnM79f36ur5cp7UuDKGaHQxgFZvolC+8aRIMegGdvr8Ht5Bp6h33CFlJCLTQGCW n4qA== X-Gm-Message-State: AOAM5316YkqzuXazjuLdw/PnVo1FLxDsSRaLMYJ30QLtGIGacX6TvTCH HZbApnY3RPH1M1YAsJU/WAckvcIBiEU= X-Google-Smtp-Source: ABdhPJxFGpccCnuJ+faRjUTD7YYWclLKvK29eLtz5AtRjy6lWqzweku7y0b4vn4Rk/bYdAOlneG50w== X-Received: by 2002:a17:90b:2251:b0:1e6:76a8:44f3 with SMTP id hk17-20020a17090b225100b001e676a844f3mr12757332pjb.71.1655079240003; Sun, 12 Jun 2022 17:14:00 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-8622-f08c-6751-b8f0.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:8622:f08c:6751:b8f0]) by smtp.gmail.com with ESMTPSA id jg19-20020a17090326d300b00167729dfe0bsm3596514plb.168.2022.06.12.17.13.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jun 2022 17:13:59 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1030.google.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:291114 Archived-At: Richard Stallman writes: > > One key reason I worry about going down that road is that I suspect it > > would complicate org's syntax. Two key benefits of org mode is that the > > basic syntax is simple and it maps reasonably consistently acorss > > different output formats. However, this flexibility does come at a cost. > > To provide consistency across export formats, the basic formatting > > 'concepts' need to be somewhat 'generalised', which means at times you > > will loose some of the more advanced or sophisticated formatting power > > of some export back-ends. > > I suspect we are slightly miscommunicating, because Texinfo already > generates several different formats of output, and each markup construct > is carefully defined about how it should appear in each output format. > > So I'm sure it is possible to define additional markup constucts and > make each one do, in each output format, what Texinfo would (or does) > do with it. > > The only hard part is finding syntax for them. > Perhaps, though I tend to feel you may have misconceptions regarding the purpose of org and its main design goals. The org mode syntax, especially the syntax for markup (markdown), is very small and concise. This is one of its big strengths. It is also one of the main reasons various markdown dialects have become so popular and why we have so many different markdown dialects - people don't want a rich syntax supporting numerous different sematic elements. They just want a very few. In fact, despite the strong arguments in favour of semantic markup, people tend to prefer typographical markup - italics, bold, underline, etc and they want a markup where they don't have to constantly wonder if they have selected the correct semantic tag for a certain bit of text. They want something which is easy to write in, which does not require referring to a manual to lookup different semantic tags and something which is easier than HTML, LaTeX, TexInfo, odt, xml, etc. I also think the statement "The only hard part is finding syntax for them." is a huge understatement. There are already a couple of requested syntax changes for markup which IMO have far greater merit than supporting more texinfo sematnic markup, which have not been implemented primarily due to the difficulty of ding so in a consistent manner which will not also break the large amount of existing org data out there. You mentioned in another thread that one of the big issues with texinfo was that maintenance of the tex part, used primarily for the printed representation, was difficult to maintain these days (assuming lack of people with expertise in tex). I just wanted to point out that much of the output formatting org supports is also achieved via tex and latex. Chances are that if we extended org syntax to support the broader set of texinfo markup, we would also inherit those same issues. At the very least, we would not be escaping from tex simply because we moved to org mode. Where I think there is a misunderstanding of org is with the emphasis which appears to be occurring on the markup and formatting aspects of org. Org's ability to support a small markdown dialect and generate output in various formats is not org's main emphasis. Org's primary role is not that of being a documentation authoring tool. Org is about a lot more, it is about information gathering and management, task and time management, information capture, 'executable' notes and literate programming and lab books with convenient outline editing support. As the name suggests, it is about helping to organise your life. It isn't about writing documentation. The fact it can support multiple output formats and produce reasonable looking documents is certainly part of it, but in some ways, that was the low hanging fruit which was relatively easy to achieve once all the other parts were in place. If a replacement for texinfo is required, then lets take the lessons we have learned from texinfo, latex/tex, xml, html, markdown and org and implement something appropriate. This might seem like too much of a task, but that is probably what people said when Carsten started developing org mode. There are many ways org mode can be improved. Current work to clarify and refine the syntax, provide a solid and efficient parser, improved font-locking and formatting and more consistent and rich API for both extensions and new export backends are far more critical than adding additional markup/markdown syntax to enable org mode to replace texinfo. IMO such changes are not only misguided, they have the real potential to adversely impact org by making things more complicated and harder to maintain, destroying the advantage of a very small and easy to use markup and moving the focus towards becoming an authoring tool rather than a personal data organisation aid.