inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)

["Juan Manuel Macías" <maciaschain@posteo.net>]

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?