From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Org mode and Emacs (was: Convert README.org to plain text README while installing package) Date: Tue, 14 Jun 2022 21:18:58 +0800 Message-ID: <87v8t3wfgd.fsf@localhost> 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="19058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, 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 Tue Jun 14 15:19:19 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 1o16Ry-0004iU-Iy for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 15:19:18 +0200 Original-Received: from localhost ([::1]:37638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o16Rx-0000a4-MC for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 09:19:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o16Qo-0007k5-Q9 for emacs-devel@gnu.org; Tue, 14 Jun 2022 09:18:07 -0400 Original-Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:34581) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o16Qa-0002eI-JG; Tue, 14 Jun 2022 09:17:54 -0400 Original-Received: by mail-pl1-x62c.google.com with SMTP id i15so7757548plr.1; Tue, 14 Jun 2022 06:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=ZFkYtpDdwgqNMDsbnpNbfk1rxbCfZhdnw1bSYmdoQWY=; b=No8Ez3NtozhLVre/MsTwPRUqk2/qyK0rRYl+6g6j7963tfYeD3ya97PhJ/7TdBMdhB 1DP3tr5Re5hdjR5yFVtBK8ztoqmNsDzhV8JS+J26522U+dxaVvkNhmvHp2nx0KpSGbK7 1cLwWDbfjbS4CrwEDuX5lHOzrIzNy/JW63Hi5+K9J0qqwrZqPmUNopoVN/750f+da8jm sido2yreO1EMedxal4XkQPHmf/zWkc/4dyVddmN3uGAL9vNOPpgtfW23tCQ2zGE9ZTcF kV+lJNlYs4m1UqyqeJQpF9xTZZBhEFMjq6Uw41/TYzzumadCQ/aQ+j+mfw5petzc7cAm M0Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=ZFkYtpDdwgqNMDsbnpNbfk1rxbCfZhdnw1bSYmdoQWY=; b=MpjLiMtJx+luW/9SQdxS5leS8BgRIhpbFqbGAHXMqpNPGZc1K8uyiqat2k6TaeM8Db X1dLBLBTjRhsSANvJszGl4Cyyv8Udv4HHr182qRNbLCH4vyxMB27Abm3GQeAnvXX8upt JoSux+ur04J+/5oAOb76+z9ZjxuftYxlPjT9bBtZNyMBHb6K/OlP+rK4MepHCAQbfoWj 63jB0T6vRa3IA9On2v2xa+083nzjMukgkBbRBoi8m/li6sGj6TUYCiIXDvvUE1nKnR1S 73blqHVY0cso053bpdyVd6XM3NSNnnkY83OygXSzry4BQ66BdtAyejoFl0yLKQDTIXNz Lzzg== X-Gm-Message-State: AJIora8ZgIx8GzuF+x1WzTvuI/6DkVAb09nvYc3BRPA8AsRork8ZTkFF hlQO+okothVGmumCj8FbnhCXrtl/PNyenjuH X-Google-Smtp-Source: AGRyM1tXHiQmTxuMs4gIKWeD/22NEBA6r5LrkIVmIohU8grBYFpjkt0qwmNdQ/rPg1ItZCIrCATM1A== X-Received: by 2002:a17:90b:4acb:b0:1e8:67df:6c61 with SMTP id mh11-20020a17090b4acb00b001e867df6c61mr4599913pjb.224.1655212668821; Tue, 14 Jun 2022 06:17:48 -0700 (PDT) Original-Received: from localhost ([155.94.207.39]) by smtp.gmail.com with ESMTPSA id y188-20020a6264c5000000b0051853e6617fsm7479018pfb.89.2022.06.14.06.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jun 2022 06:17:48 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=yantar92@gmail.com; helo=mail-pl1-x62c.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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_ENVFROM_END_DIGIT=0.25, 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:291176 Archived-At: Richard Stallman writes: > They are in the Texinfo manual. Look at node "Indicating", which is > section 7.1 in the version I have in Info. Thanks! > > 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. As I stated in another message, we may not need to define additional markup constructs. texinfo-specific markup appears to be a little bit too specific for general-purpose formatting aimed by Org. Instead of modifying Org syntax (and forcing all third-party packages adapt), we can leverage the fact that parts of Org syntax are programmable in Elisp. Org provides links as a flexible markup element - its export to different formats can be arbitrarily customized (via function). See A.3 Adding Hyperlink Types of Org manual. For paragraph-level constructs, there is org-export-filter-parse-tree-functions and external https://github.com/alhassy/org-special-block-extras We may implement something more reminiscent to link customization in future. org-export-filter-parse-tree-functions is a bit too generic (one function for everything). In summary, Org does not really need to change syntax in order to support full texinfo markup. AFAIU, the missing parts are some of the texinfo-specific markup elements, abbreviations, and generating index. They all can be implemented as new libraries. Abbreviations and index are WIP at https://github.com/tecosaur/org-glossary The texinfo-specific markup can be another (optionally loaded) Org library. > > As pointed out elswhere in this thread, org could support missing > > texinfo syntax using texinfo specific blocks. However, that isn't a > > great experience from an authoring perspective. It is fine if you only > > need to do it occasionally, but if you have to constantly add such > > blocks in order to get really well formatted texinfo output, > > This is rather vague. Why do you thik this would be difficult to use > Can we find a solution to make it easy to use? This was a reference to Org export blocks: #+begin_export latex This text will only appear when exported to \LaTeX, not to any other format. #+end_export They may be not great experience what one needs to do something like #+begin_export texinfo @var{test} will only appear in .texi output. #+end_export #+begin_export latex \emph{test} will only appear in .tex output. #+end_export many times in the same .org document. However, we have special blocks for this purpose. They are extendable, as I descibed above. Though some improvements in Org core might be needed if we have to use this extensibility more frequently. Best, Ihor