From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [babel] using #+call for inline results Date: Thu, 23 Jun 2011 21:55:17 +0200 Message-ID: <871uykgw62.fsf@gmail.com> References: <87mxhaunsi.fsf@ucl.ac.uk> <87mxh9omwb.fsf@gmail.com> <87mxh9pvz8.fsf@ucl.ac.uk> <87sjr1i040.fsf@gmail.com> <874o3hvuh0.fsf@ucl.ac.uk> <87sjr0psih.fsf@gmail.com> <87r56k78wm.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:36398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZpzw-00052l-LU for emacs-orgmode@gnu.org; Thu, 23 Jun 2011 15:55:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZpzu-0007eh-Nm for emacs-orgmode@gnu.org; Thu, 23 Jun 2011 15:55:32 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:48378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZpzu-0007eb-Ee for emacs-orgmode@gnu.org; Thu, 23 Jun 2011 15:55:30 -0400 Received: by wyg36 with SMTP id 36so1864295wyg.0 for ; Thu, 23 Jun 2011 12:55:29 -0700 (PDT) In-Reply-To: <87r56k78wm.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Thu, 23 Jun 2011 18:30:17 +0100") 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: Eric Schulte Cc: emacs-orgmode@gnu.org Eric S Fraga writes: >> I see no difference between the paragraph and the list item: in both >> cases, the table doesn't appear, as it has been moved right after the >> headline by `org-export-blocks-preprocess' during export. >> >> Are we observing the same phenomenon? > > No, I don't believe so. Nothing to do with the table; all to do with > the two inline babel evaluations. The latex I get exported by this > snippet of org code: > > The relative volatility is src_octave[:var it=benzene-chlorobenzene-relative-volatility :results output raw]{disp(it);}. > > If I put the result in a list: > - it does not work as the result is src_octave[:var it=benzene-chlorobenzene-relative-volatility :results output raw]{disp(it);} and the list processing is confused. > > is > > The relative volatility is 7.8578 > . > > If I put the result in a list: > > \begin{itemize} > \item it does not work as the result is 7.8578 > \end{itemize} > and the list processing is confused. > ORG-LIST-END-MARKER Again, we get different outputs. *sighs* > The in-paragraph processing is "fine" (modulo a spurious newline). > However, the list item is terminated prematurely immediately after the > result of the babel code evaluation *and* there is an > =ORG-LIST-END-MARKER= left over! Both are directly related anyway. > I guess the problem is due to babel moving things around during the > list processing? > > From the recent messages, it sounds like there is a sort of race > condition being caused by some list processing followed by babel > processing and then again by list processing during the export process? > Or have I misunderstood the problems? Not really. The problem is that babel doesn't pay much attention to its output. It may add blank lines, put text to column 0, etc. Thus, list processing is done in two parts. Before expanding babel blocks, list endings are marked with that ORG-LIST-END-MARKER string, in order to ignore blank lines that might have been added. After the expanding, lists are read again and stuffed with text properties, mainly for line by line exporters (which lack context understanding to properly export lists, but that's another topic). Even with that extra care, problems arise (often due to text put at column 0). One solution would be for babel to properly set the indentation of its output, or set the `original-indentation' property of that output to the indentation of the original block (which is usually done, but, looking at the recent problems, not always). Well, all this babbling doesn't quite help to solve the issue at hand... Regards, -- Nicolas Goaziou