Re: [proof of concept] inline language blocks

[Max Nikulin]

On 29/02/2024 17:41, Juan Manuel Macías wrote:
> Max Nikulin writes:
> > I do not try to dispute \foo and class="foo" as default behavior. I
> > suggest to implement possibility to override default behavior of
> > &foo{text} to \bar{text} and <bar>text</bar>. The same is applicable
> > for anonymous objects
> >
> >       &_[:latex_command bar :html_element bar]{text}
>
> Maxim, I insist that I follow the logic of the "large" special blocks.

Export of special blocks may be extended as well.

> Anyway, I think your example only makes sense in HTML, or at least I
> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
> does seem sensible to me that someone would want to change the tags.
> Maybe with a :html-tag, or something like that.

Consider a document aimed to be exported to different formats. It is 
unlikely that names of commands, elements, classes, etc. match for all 
of them.

> As for :latex-command, if I understand it correctly, I don't quite see
> how useful this could be:
>
> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
>
> when it is simpler to put:
>
> &bar{text}

Command may require additional arguments and it should be convenient to 
define shortcuts to the same command with different arguments:

&la{text} => \foreignlanguage{latin}{text}
&es{text} => \foreinglanguage{spanish}{text}

> The same thing happens with the anonymous variant:
>
> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>
> which is identical to putting &foo{text}
>
> The anonymous variant would be equivalent in LaTeX to a
> \begingroup...\endgroup, or rather to {...}. One could add all the
> commands one wants within the group simply with :prelatex:
>
> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>
> ==> {\foo\bar\vaz\blah{}text}

The idea is to not add \begingroup and \endgroup if LaTeX command is 
specified (or to control it by a dedicated attribute). Again, consider a 
document suitable for multiple export formats.

I think, flexibility in respect to underlying commands/classes/elements 
allows to minimize changes in documents later. Sometimes it is necessary 
to switch to another LaTeX package, CSS framework, etc. It allows usage 
semantic names within Org documents despite they may be exported to the 
same command.

> In any case, I think that my implementation leaves open the possibility
> of extending it with everything you mentioned, or anything else.

The question is proper balance of built-in features, flexibility, 
implementation complexity. It would be unfortunate if most of users will 
have to create custom backends even for basic documents.