Max Nikulin <maniku...@gmail.com> writes: > On 01/10/2022 11:08, Ihor Radchenko wrote: >> 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.
Creating derived backend will force users to use that non-standard backend for export - inconvenient. Especially for third-party backends. :export property, among other things, can also provide a reasonable fallback for arbitrary backend not considered in advance. > 1. Interface is rather different from the derived backend property. > Instead of org-element object only selected properties (and backend > communication channel is available). Is it? :export function for links is taking similar parameters with the other export transcoders. > 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. We may provide something like :export-filter-object that will act similar to `:filter-parse-tree' and replace the original link object with arbitrary Org AST. > 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. No. There is no need to consider every possible backend. There could be an export handler that will provide a fallback for unknown backend, if needed. > 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. Please do remember that texinfo commands, are _not_ verbatim. They can contain other markup inside. I'd rather look at them as extended emphasis. Their contents must be parsed as well. > 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. Agree. See export filter idea. -- 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>
