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: Thu, 06 Oct 2022 13:55:38 +0800 [thread overview]
Message-ID: <87edvl5wdh.fsf@localhost> (raw)
In-Reply-To: <thhn7h$12b8$1@ciao.gmane.io>
Max Nikulin <manikulin@gmail.com> writes:
> It seems I completely failed trying to express my idea.
>
> Instead of extending Org grammar (syntax), I suggest to change behavior
> of source blocks during export. In addition to current :results options,
> "ast" may be added. Its effect is that instead of adding text to export
> buffer that is parsed as Org markup, it causes insertion of a branch of
> syntax tree into original parse results. I admit, during export it may
> be necessary to iterate over source blocks one more time at a later stage.
So, do I understand it correctly that you are _not_ suggesting the AST
format _instead_ of the discussed inline blocks?
> Such source blocks should return "Org Syntax Tree", a simplified variant
> of org-element. It allows to change implementation details and e.g. to
> use vectors instead of lists for attributes in org-element. A converter
> from Org Syntax Tree to org-element should be implemented.
Doesn't it effectively mean that we need to introduce yet another Org
element syntax---"Simplified AST"?
> Certainly such format may be used directly as src_ost{(code (:class var)
> "language")} inline snippets or as
>
> #+begin_src ost
> (code nil ("libtree-{sitter}-"
> (code (:class var) "\"language\"")
> "."
> (code (:class var) "ext")))
> #+end_src
>
> block-level elements. However I expect that it is the last resort option
> when there is no way to express desired construct in some other way.
I can foresee issues when we insert, say, code object in place of
paragraph element. The consequences might be drastic. Unless we just
allow users to shoot their own leg.
> I think, more convenient org-babel backends may be created to parse
> TeX-like (texinfo-like) or SGML-like (XML-like) syntax into Org Syntax
> Tree hierarchy. The essential idea is that outside of source blocks
> usual lightweight markup is used. Source blocks however have just a few
> special characters ([\{}], [@{}], or [&<>], etc.) to reduce issues with
> escaping for regular text or verbatim-like commands.
This is not a bad idea, but I feel like it is getting a bit too far from
the syntax discussion herein. You might open a new thread about
importing foreign syntax into Org.
>>> (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.
>
> By this example I was trying to show how to express @var, @samp, @file
> without introducing of new custom objects. I do not see any problem with
> verbosity of such format, it may be used for really special cases only,
> while some more convenient markup is used for more simple cases.
I was comparing the inline block vs. your AST proposal. If the AST idea
is complementary, I see no issue.
>>> 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 do not mind to have some "span" object to assign attributes to its
> direct children. I used link-like prefix object just because a proof of
> concept may be tried with no changes in Org. It does not require support
> of nested objects. There is no existing syntax for such "span" objects,
> but perhaps it is not necessary and source blocks should be used instead
> for special needs.
The problem is that instead of supporting nested objects we will have to
support "previous object changing the meaning of subsequent", which is
more fundamental change.
I envision the new inline blocks to allow assigning attributes to
children. These new inline blocks must not have issues with nesting by
design.
--
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>
next prev parent reply other threads:[~2022-10-06 5:56 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
2022-10-04 16:32 ` Max Nikulin
2022-10-06 5:55 ` Ihor Radchenko [this message]
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=87edvl5wdh.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).