From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thibaut Verron Subject: Re: Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations Date: Thu, 26 Jun 2014 15:53:55 +0200 Message-ID: References: <878uoknegl.fsf@nicolasgoaziou.fr> <871tuboln9.fsf@nicolasgoaziou.fr> Reply-To: thibaut.verron@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3d8d04613ff04fcbd870a Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0A87-0006jP-5t for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 09:54:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0A81-0004x2-Cw for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 09:54:23 -0400 Received: from mail-la0-x22a.google.com ([2a00:1450:4010:c03::22a]:33567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0A80-0004wq-Vu for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 09:54:17 -0400 Received: by mail-la0-f42.google.com with SMTP id pn19so1933015lab.29 for ; Thu, 26 Jun 2014 06:54:15 -0700 (PDT) In-Reply-To: <871tuboln9.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Thibaut Verron , emacs-orgmode --001a11c3d8d04613ff04fcbd870a Content-Type: text/plain; charset=UTF-8 2014-06-26 15:17 GMT+02:00 Nicolas Goaziou : > Thibaut Verron 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). > Of course, I did not mean it for org-mode buffers! ;) > > 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)))) > > Indeed it does work. But, unless I am mistaken, this is exactly the definition given here: http://orgmode.org/manual/Translator-functions.html#Translator-functions and so I was not wrong, this used to work as I expected. I suspect that this change (regression?) will cause problems to a lot of other users when they will upgrade their org to the current version. Would changing the last lines of `orgtbl-to-latex` to something like this work as a long-term solution? (require 'ox-latex) (let* ((*orgtbl-verbatim* (plist-get params :verbatim)) (backend (if *orgtbl-verbatim* nil 'latex))) (orgtbl-to-generic table (org-combine-plists params2 params) backend)))) Thanks for your time, Thibaut verron --001a11c3d8d04613ff04fcbd870a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2014= -06-26 15:17 GMT+02:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>= ;:
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 t= o
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).

Of course, I did not mean it for org-mode buffers! ;)
=C2= =A0

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<= br> 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:
>
> =C2=A0 (defun tv/orgtbl-to-latex-verbatim (table params)
> =C2=A0 =C2=A0 (flet ((org-export-string-as
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (string backend &optiona= l b e)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string))
> =C2=A0 =C2=A0 =C2=A0(orgtbl-to-latex table params)))
>
> However, it is extra dirty, and ignoring so many parameters in a funct= ion
> is probably not safe. :-)

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

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


Indeed it does work.=C2=A0
<= br>
But, unless I am mistaken, this is exactly the definition giv= en here:=C2=A0http://orgmode.org/manual/Translator-functions.html= #Translator-functions
and so I was not wrong, this used to work as I expected.
I suspect that this change (regression?= ) will cause problems to a lot of other users when they will upgrade their = org to the current version.

= Would changing the last lines of `orgtbl-to-latex` to something like this w= ork as a long-term solution?

<= /font>
=C2= =A0 =C2=A0 (require 'ox-latex)
=C2=A0 =C2=A0 (let* ((*orgtbl-verbatim* (plist-get params :v= erbatim))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0(backend (if *orgtbl-verbatim* nil 'latex)))
=C2=A0 =C2=A0 =C2=A0 (orgtbl-to-gene= ric table (org-combine-plists params2 params) backend))))

Thanks for your time,

Thibaut = verron
--001a11c3d8d04613ff04fcbd870a--