emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
Date: Mon, 03 Oct 2022 12:36:20 +0800	[thread overview]
Message-ID: <87r0zpy14r.fsf@localhost> (raw)
In-Reply-To: <thce6m$apa$1@ciao.gmane.io>

Max Nikulin <manikulin@gmail.com> writes:

> On 02/10/2022 11:59, Ihor Radchenko wrote:
>> Can you please illustrate how to use the described AST markup for the
>> following Texinfo snippet:
>> 
>>      By convention, the dynamic library for @var{language} is
>>      @code{libtree-@{sitter@}-@var{"language"}.@var{ext}}, where @var{ext} is the
>>      system-specific extension for dynamic libraries.
>
> If you are asking how to represent such construct without introducing 
> custom elements then (it may be e.g. :type, not :class) parsed AST 
> should be like
>
>      (code nil ("libtree-{sitter}-"
>                 (code (:class var) "\"language\"")
>                 "."
>                 (code (:class var) "ext")))

This is not much different from @name[nil]{<contents>} idea, but
more verbose.

Also, more importantly, I strongly dislike the need to wrap the text
into "". You will have to escape \". And it will force third-party
parsers to re-implement Elisp sexp reader.

> If there was some syntax for object attributes then simple cases would 
> be like
>
>      [[attr:(:class var)]]~language~

I do not like this idea. It will require non-trivial changes in Org
parser and fontification.

Using dedicated object properties or at least inheriting properties from
:parent is the style we employ more commonly across the code:

@var{language}
or
@code[:class var]{language}
or
@attr[:class var]{~language~}

> I have no idea concerning particular markup that can be used inside 
> source blocks. It might be LaTeX-like commands as discussed in the 
> sibling subthread or HTML (XML) based syntax that is more verbose than 
> TeX-like notation.
>
>      By convention, the dynamic library
>      for src_alt{\code[class=var]{language}} is
>  
> src_alt{\code{libtree-\{sitter\}-\code[class=var]{"language"}.\code[class=var]{ext}}},
>      where src_alt{\code[class=var]{ext}} is the
>      system-specific extension for dynamic libraries.

I am against the idea of LaTeX-like commands. It will clash with
latex-fragment object type.
https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Fragments

> or
>
>      By convention, the dynamic library for
>      src_alt{<code class="var">language</code>} is
>      src_alt{<code>libtree-{sitter}-<code 
> class="var">"language"</code>.<code class="var">ext</code></code>},
>      where src_alt{<code class="var">ext</code>} is the
>      system-specific extension for dynamic libraries.

This style will indeed make things easier for the parser. But I find it
too verbose for practical usage. This is why I instead proposed the idea
with variable number of brackets: @code{{can have } inside}}.

> Hypothetical "alt" babel language has default :results ast :export 
> results header arguments to inject AST bypassing Org markup stage.

The problem with src block emitting AST is clashing with the way src
blocks work during export. What `org-export-as' does is replacing/adding
src block output into the actual Org buffer text before the parsing is
done.

Handling direct AST sexps will require a rewrite on how babel
integration with export works.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


  reply	other threads:[~2022-10-03  4:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1ocmvz-0002iB-2M@fencepost.gnu.org>
2022-09-30  3:31 ` [HELP] Fwd: Org format as a new standard source format for GNU manuals Ihor Radchenko
2022-09-30  3:49   ` Samuel Wales
2022-09-30  5:47   ` Thomas S. Dye
2022-09-30  8:25   ` Christopher M. Miles
2022-09-30 12:49   ` Max Nikulin
2022-10-01  3:30     ` Ihor Radchenko
2022-10-01 10:42       ` Max Nikulin
2022-10-01 11:01         ` Ihor Radchenko
2022-10-01 11:27           ` Max Nikulin
2022-10-02  4:59             ` Ihor Radchenko
2022-10-02 10:38               ` Fraga, Eric
2022-10-02 13:02                 ` Ihor Radchenko
2022-10-02 13:21                   ` Fraga, Eric
2022-10-02 13:47                   ` Juan Manuel Macías
2022-10-03  4:23                     ` Ihor Radchenko
2022-10-04 20:28                       ` Juan Manuel Macías
2022-10-05  6:56                         ` Rick Lupton
2022-10-06  3:39                           ` Ihor Radchenko
2022-10-02 16:28               ` Max Nikulin
2022-10-03  4:36                 ` Ihor Radchenko [this message]
2022-10-04 16:32                   ` Max Nikulin
2022-10-06  5:55                     ` Ihor Radchenko
2022-09-30 20:36   ` Tim Cross
2022-10-01  4:08     ` Ihor Radchenko
2022-10-01  8:01       ` Tim Cross
2022-10-01 15:08       ` Max Nikulin
2022-10-03  4:19         ` Ihor Radchenko
2022-10-07 22:48   ` Richard Stallman
2022-10-08  6:52     ` Ihor Radchenko
2022-10-08 22:34       ` Richard Stallman
2022-10-11  3:03         ` Robert Weiner
2022-10-11 12:16           ` Ihor Radchenko
2022-10-12 22:00           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0zpy14r.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).