Max Nikulin <maniku...@gmail.com> writes:
> On 30/09/2022 10:31, Ihor Radchenko wrote:
>>
>> Texinfo provides numerous subtle distinctions that show up clearly in
>> each of these output formats. Compare, for example, @var, @dfn and
>> @emph; compare @code, @samp, @file, @command, @option, @kbd, and @key.
>
> I have not read the emacs-devel thread, so I may ask about something
> that already has been discussed.
>
> Are there cases when texinfo may use nested formatting commands of the
> same type, something like @samp{a @code{b @samp{c} d} e}? My concern is
> that current org-element parser may be a blocker.
AFAIK, the only nested construct in Texinfo spec is
@acronym{GNU, @acronym{GNU}'s Not Unix}
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040acronym
But it should not be a blocker. We can use two different elements for
this instead or employ the requirement of balanced parenthesis inside,
similar to what we do in the HEADERS for inline src blocks
https://orgmode.org/worg/dev/org-syntax.html#Source_Blocks
> Another point is that most of the mentioned commands a close to
> verbatim, but Org has much more special characters recognized as markup
> and no markup is allowed inside Org verbatim snippets. Escaping (by zero
> width spaces?) of code and samples may be prohibitively inconvenient in
> Org if markup should be recognized inside.
We need a new special object type for markup that does not suffer from
the limitations of our current single-char-style *markup* constructs.
(It is not even solely motivated by this request from RMS; we just need
something to allow whitespace in verbatim boundaries)
> One more point is external tools like pandoc export from Org to other
> formats. When Org extensions are implemented in elisp, such tools become
> hardly usable. Unsure if some kind of declarative style sheets will be
> enough.
We already have Org extensions for links. I envision supporting GNU
manuals in a similar fashion. Only a subset of universally useful
extensions will become the actual part of Org syntax spec. At the end,
Org should remain generic export format without going too far into
manual-specific requirements. Specific exports should be supported
optionally, similar to our ol-*.el libraries.
--
Ihor Radchenko,
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
