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.
