Thibaut Verron <thibaut.verron@gmail.com> writes:

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

I disagree in the general case. The most logical default for Org is to
treat contents as plain text and ensure that the export conforms to what
appears in the buffer. As a bonus, it can leave LaTeX code as-is when it
recognizes some, which depends on Org's understanding of LaTeX syntax
(hence the limitations I'm talking about).

Now, in the context of a LaTeX buffer using orgtbl minor mode, it could
make sense in some situations to treat cell contents verbatim. I don't
think it should be the default, but there could be an option for that.
Anyway, there's a solution, see below.

> Apparently not, the following quick attempt seems to be doing the job fine
> enough:
>
>   (defun tv/orgtbl-to-latex-verbatim (table params)
>     (flet ((org-export-string-as
>             (string backend &optional b e)
>             string))
>      (orgtbl-to-latex table params)))
>
> However, it is extra dirty, and ignoring so many parameters in a function
> is probably not safe. :-)

I think defining your own translator function is the way to go. For
example, the following (untested) could work:

  (defun my-orgtbl-to-latex-verbatim (table params)
    (let* ((alignment (mapconcat (lambda (x) (if x "r" "l"))
                               org-table-last-alignment ""))
         (params2
          (list
           :tstart (concat "\\begin{tabular}{" alignment "}")
           :tend "\\end{tabular}"
           :lstart "" :lend " \\\\" :sep " & "
           :efmt "%s\\,(%s)" :hline "\\hline")))
      (orgtbl-to-generic table (org-combine-plists params2 params))))