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 Date: Sat, 09 Sep 2023 09:36:26 +0000 Message-ID: <87ledf7ko5.fsf@localhost> References: <83msyemjx8.fsf@gnu.org> <871qfpoij6.fsf@gnu.org> <87fs45ivyo.fsf@localhost> <87h6okga15.fsf@localhost> <87cyz61cbp.fsf@localhost> <87v8cuqtkr.fsf@localhost> <87sf7rsfpd.fsf@localhost> <8334zr32ih.fsf@gnu.org> <87edjbsc8k.fsf@localhost> <83r0nb1mb1.fsf@gnu.org> <871qfbsaju.fsf@localhost> <83pm2v1fyw.fsf@gnu.org> <87y1hjqnzq.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="15089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 09 11:36:32 2023 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 1qeuOF-0003fC-V0 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Sep 2023 11:36:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeuNM-00046Q-Rp; Sat, 09 Sep 2023 05:35:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeuNL-00045w-AE for emacs-devel@gnu.org; Sat, 09 Sep 2023 05:35:35 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeuNF-0002NM-IH for emacs-devel@gnu.org; Sat, 09 Sep 2023 05:35:35 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A2887240106 for ; Sat, 9 Sep 2023 11:35:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1694252127; bh=9gGMIzB3A07omIzbg2j46+A/nqG2NCbha7vwfChnLWs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ExU0damtKSb+9eMxrVKhmSY4Orzn5NRnTgchwXl9VKwwci69mSBZ6b3hptItAVj9a 2vdFRZYURyKC22xziOsP4gHG1IQke1niywTgsNN5zo91ekiMFi11MqgBq1nQtlIZIi ZLBpqKx3VcMuz0Cf3YyKEmQqFemqpvUJkIq6p5ax0xJvKm5ui+Su6iue1+Xu0GFCr4 /sF380gpmSBnnpwl+umXpezowdpNDQGjE8legZP/Is6kKDpeZtJQUGZofRLWoWlL3p mUgRZW8gyHlwYC3rU/stXpsqdP38esZdiJN5mXUv80Rpy8W2KLjKjcPvj2r91E3oBF DjO+ep1g954hQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RjSWd3Pxlz6tyG; Sat, 9 Sep 2023 11:35:25 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310393 Archived-At: Richard Stallman writes: > > The way I see Org markup extension would make it easy to users add new > > custom markup, as needed. Then, no frequent changes to the base markup > > will be necessary to accommodate for less common use cases. > > I see a possible ambiguity and point of confusion. When you say, > "extension", do you mean "a package that gets loaded on top of > ordinary Org mode"? That's what I thought it meant. A package or user Elisp snippet. For example, Org currently allows extending hyperlinks like (defun org-man-export (link description format _) "Export a man page link from Org files." (let ((path (format "http://man.he.net/?topic=%s§ion=all" link)) (desc (or description link))) (pcase format (`html (format "%s" path desc)) (`latex (format "\\href{%s}{%s}" path desc)) (`texinfo (format "@uref{%s,%s}" path desc)) (`ascii (format "%s (%s)" desc path)) (t path)))) (org-link-set-parameters "man" :export #'org-man-export) Then, links will be formatted arbitrarily during export. The same idea will be for markup syntax: @var{variable-name} will, in future, be defined as (org-markup-set-parameters "var" :export #'my-export-function-for-var) @var is probably something we will have within Org, but if one needs some weird markup for a specific manual, it will equally be possible to define @my-special-markup{contents} via (org-markup-set-parameters "my-special-markup" :export #'custom-export-formatter) > Implementing some of the Texinfo constructs in such a package, perhaps > called org-texinfo, is an implementation detail as far as I'm > concerned. > > But now I think maybe you mean something else -- that you propose > to add some sort of limited macro definition facility and have the > missing Texinfo constructs be defined using that. Is that it? We might allow in-document definitions like: #+markup[html]: my-special-markup %s #+markup[latex]: my-special-markup \foo{%s} ... but the `org-markup-set-parameters' is what we preliminarily agreed upon for now. Further features are to be discussed later. > To be adequate for this job, the macro definition facility needs to be > more powerful than they usually are. The expansion of one construct > needs to depend on the output format being generated, and sometimes > the expansion of construct A depends on whether it is inside construct > B. > If the facility can do that, I think it will suffice for nearly all of > the missing Texinfo constructs. If you think of this as a method to > simplify part of the implementation of Texinfo in Org, it may work. Org is already capable to provide access to the full parse tree when expanding links with custom :export function. The same can be done for markup constructs. Much more difficult if one wants in-document definitions though. > But be prepared for exeptions, constructs that need special handling! > If you think of this as a way to keep Org itself free of Texinfo > impurities, it won't work. May you elaborate about special handling? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at