[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HELP] Fwd: Org format as a new standard source format for GNU manua
From: |
Ihor Radchenko |
Subject: |
Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals |
Date: |
Mon, 03 Oct 2022 12:19:18 +0800 |
Max Nikulin <manikulin@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>
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Ihor Radchenko, 2022/10/01
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Max Nikulin, 2022/10/01
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Ihor Radchenko, 2022/10/01
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Max Nikulin, 2022/10/01
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Ihor Radchenko, 2022/10/02
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Fraga, Eric, 2022/10/02
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Ihor Radchenko, 2022/10/02
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Fraga, Eric, 2022/10/02
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Juan Manuel Macías, 2022/10/02
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Ihor Radchenko, 2022/10/03
- Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals, Juan Manuel Macías, 2022/10/04