Re: [proof of concept] inline language blocks

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

Max Nikulin writes:

>> 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.

It makes sense, although I have never encountered a case like this.
Usually (and returning to the example of the large special blocks), if
in org I put something like:

#+begin_foo
...
#+end_foo

I try to ensure that there is a "foo" environment in LaTeX, a "foo" class
in html or a "foo" style in odt (now I don't remember if the odt exporter
produces paragraph styles from special blocks. I don't think so).

In any case, on second thought, maybe someone wants to reuse a LaTeX
preamble, css style sheets or any odt templates. I see no problem, then,
in there being attributes like :latex-command, :html-tag, :odt-style :html-attribute,
etc., which override the default values.

>> 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}

With the current implementation:

#+options: inline-special-block-aliases:(("bar" :prelatex [bar]) ("baz" :prelatex [baz]))

&foo[@bar@]{lorem ipsum} ==> \foo[bar]{lorem ipsum}
&foo[@baz@]{lorem ipsum} ==> \foo[baz]{lorem ipsum}

Your example is less verbose, but with this implementation you can do combinations, it's
more granular, I think:

&foo[@bar@ :smallcaps t]{lorem ipsum} ==> {\scshape\foo[bar]{lorem ipsum}}
&foo[@baz@ :lang it]{lorem ipsum} ==> \foo[baz]{\foreignlanguage{italian}{lorem ipsum}}

I think this is quite flexible and leaves a great deal of freedom to the user.

>> 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.

Indeed, if the :latex-command attr is implemented should work in both
variants. In such a way, perhaps:

&_[:latex-command foo]{lorem} ==> \foo{lorem}

> 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.

We can continue the discussion when I publish my experimental branch and
share the link. I'm a little late because I want to make some
corrections to the code first.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía