Max Nikulin writes: > I am afraid that :export will cause confusion with :exports for source > code blocks. Its name differs by just "s" but possible values have > nothing common.
I agree. At the moment two alternative names come to mind: :backends or :export-rules > Another issue is more general and should apply e.g. to HTML attributes > as well. Consider > > --- 8< --- > > #+options: inline-special-block-aliases:(("kbd" :export "html*" > :html-tag kbd)) > > @kbd{Default} and @kbd[:export "latex*"]{LaTeX} > --- >8 --- > > It exports to > > <p>\nDefault and <kbd class="kbd">LaTeX</kbd></p> > > I would expect that "html*" is inherited from the parent declaration and > "latex*" does not override it, so > > <p>\nDefault and LaTeX</p> But it is the expected result in all attributes. If an attribute of the same type as the one declared in the alias is added, the value is overwritten. In any case, since in this case the attribute allows cumulative values, I think the approach should be at the level of the attribute name itself and not the code to manage the export rules. For example: :export [or whatever new name we give it] ==> normal behavior, overwrites the values :export+ ==> adds the new values to the values defined in the alias This syntax could also be extended to other cases. Perhaps we want attributes like :prelatex, :postlatex, or :html to support accumulating values. It could be easily solved from the functions of each backend. In other cases, of course, it wouldn't make sense (a block can't have two languages at the same time), but in that scenario, if someone puts :lang+, it simply wouldn't be taken into account. Wdyt?