Re: Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations

[Thibaut Verron <thibaut.verron@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3943 bytes --]

2014-06-26 12:38 GMT+02:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
> Thibaut Verron <thibaut.verron@gmail.com> writes:
>
> > I'm forwarding this question asked on stackexchange:
> > http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
> > that-braces-and-dollars-are-not-escaped
> >
> > After some investigation, it seems that the behavior is hidden deep in
> the
> > export routines, and I was wisely suggested to ask the question on this
> list
> > instead.
> >
> > I have given some tex-related details in the linked question, including
> some
> > motivations and an example, the tl;dr is that in some conditions, the
> > orgtbl-to-latex exporter will perform arbitrary escape of some
> characters in
> > the cells, or other kind of transformations:
> >
> >  $\text{test}$
> > is exported verbatim (OK).
> >
> > But
> >  \pbox{test}
> > becomes
> >  \pbox\{test\}
>
> You should upgrade to Org 8.
>
> >  {test}
> > becomes
> >  \{test\}
>
> This is intended.
>
> >  {$test$}
> > becomes
> >  \{\$test\$\}
>
> This is to be expected as matching single dollar math snippets is
> fragile. I suggest to use \(...\) instead: {\(test\)}
>
> > And the exporter seems to be trying to be smart, because it will still
> > ensure that the result is correct:
> >
> >  {$\infty$}
> > becomes
> >  \{\$$\infty$\$\}
>
> Ditto. Use \(...\). Or, better, {\infty} as \infty is an Org entity
> which will properly translated into LaTeX code.
>
> > The weirdest of all might be this one:
> >  \pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
> > becomes
> >  \pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
>
> You cannot write raw LaTeX macros with complicated arguments (e.g.,
> containing braces) in an Org buffer. In this case, you have to tell the
> exporter it is LaTeX code and don't expect it to find it out:
>
>   @@latex:\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}@@
>
> This will be ignored in any exporter but latex (and beamer).
>
> > The option `:no-export`, as expected, has no effect, since it only
> controls
> > whether `#_^&%` are escaped or not.
>
> This option doesn't exist anymore in Org 8.
>
> > Is this a known feature, or a bug? And is there a known workaround?
>
> Actually, this is consistent if you understand the limitations of Org.
> As a rule of thumb, avoid using $..$ constructs and macros with
> convoluted arguments (but "\hfill{}" and "\vspace{1cm}" are fine) when
> writing raw LaTeX in an Org buffer.
>
> For anything more complicated, use @@latex:...@@
> or #+BEGIN_LATEX...#+END_LATEX (inline and non-inline version).
>
> Again, all this assumes you are using Org 8.
>
> HTH,
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Thank you for your answer,

I forgot to repeat the information about my environment I gave on
stackexchange. In particular, this is Org 8.2.6.

Also, this is not an org buffer, but a latex buffer with the orgtbl minor
mode. Indeed I should have mentioned it in the body of the question, it's
easily missed in the title.

However, I understand that the underlying mechanism is the same as the one
used to export an org buffer to latex, and that it probably suffers from
the same limitations.
Now, are these "limitations of Org" really preventing it from exporting a
string verbatim? That would seem like the most logical default in this
situation, wouldn't it? (Disclaimer: I don't "understand the limitations of
Org", so these last questions may be ridiculous to someone who does)

Thanks,

Thibaut Verron

PS. Indeed \(..\) does work for the dollars, thank you for the tip. I
should have pointed out that \bgroup ... \egroup works as a replacement for
outermost pairs of braces too. However, I do not have any solution for the
\pbox{...} thing. And I would prefer a more robust solution which would not
require me to change the way I write the tables, because otherwise, I'd
still risk facing new unexportable constructs at random times.

[-- Attachment #2: Type: text/html, Size: 5390 bytes --]