From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals
Date: Sat, 1 Oct 2022 22:08:42 +0700 [thread overview]
Message-ID: <th9l5s$fle$1@ciao.gmane.io> (raw)
In-Reply-To: <875yh42nj9.fsf@localhost>
On 01/10/2022 11:08, Ihor Radchenko wrote:
> Tim Cross writes:
>
> I do not think that we need to add all the variety of Texinfo-specific
> constructs to the Org specification. Instead, we should add generic
> configurable syntax elements to Org. (The Texinfo-specific part will
> come as a separate library, similar to ol-*.el)
>
> In particular, I suggest to (1) extend the existing special block elements
> with Elisp-configurable :export settings; (2) add special block
> equivalent object.
While I do not mind to have flexible generic inline objects, I feel some
doubts.
Export is already customizable through creation of derived backend. For
links :export property is merely an alternative way supposed to be more
convenient. In some sense it is a way to dispatch proper handler, a kind
of virtual function table, etc. I see a couple of limitations with link
export implementation.
1. Interface is rather different from the derived backend property.
Instead of org-element object only selected properties (and backend
communication channel is available).
2. Unsure if there is a robust way to extend implementation of the
backend handler without replacing it completely. I mean a function that
modifies or sets some attributes and delegate real export to the default
handler.
Mentioned in this thread texinfo commands are not convincing reason for
special blocks from my point of view. They are different flavors of
verbatim (or code) object. If they are verbatim objects with some
additional property then they may be just exported by a backend that is
unaware of their kinds. It can be considered as graceful degradation.
For special blocks export handlers must be implemented for each backend
unless type hierarchy is someway declared.
Earlier we discussed assigning attributes for inline objects. While
nesting is not involved, it may be a way to implement necessary texinfo
commands as verbatim with class or type attribute. I am unsure if
different types of special blocks is the best way to resolve nesting
problem. Verbatim custom objects require different rules of parsing.
Actually I simplified things when wrote that a backend may be unaware of
verbatim type. When nesting is involved it should be ready at least to
nested verbatim object. E.g. markdown backend can not blindly wrap text
into backticks, it has to check if parent element is not a verbatim
snippet or a verbatim block.
next prev parent reply other threads:[~2022-10-01 15:09 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
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 [this message]
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='th9l5s$fle$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).