[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [babel] using #+call for inline results
From: |
Eric S Fraga |
Subject: |
Re: [O] [babel] using #+call for inline results |
Date: |
Thu, 23 Jun 2011 18:30:17 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) |
Nicolas Goaziou <address@hidden> writes:
> Hello,
>
> Eric S Fraga <address@hidden> writes:
>
>> For completeness, I've attached a file which shows that it *can* work
>> but also that it confuses the export of lists (Nicolas?) if the inline
>> code is in a list item.
>
> 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?
>
> Regards,
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:
--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---
is
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
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! 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?
In any case, nothing major! Just a consequence of living at the
bleeding edge ;-) Thanks for looking into these problems.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.423.g101a3)
- [O] [babel] using #+call for inline results, Eric S Fraga, 2011/06/22
- Re: [O] [babel] using #+call for inline results, Eric Schulte, 2011/06/22
- Re: [O] [babel] using #+call for inline results, Eric S Fraga, 2011/06/22
- Re: [O] [babel] using #+call for inline results, Eric Schulte, 2011/06/23
- Re: [O] [babel] using #+call for inline results, Eric S Fraga, 2011/06/23
- Re: [O] [babel] using #+call for inline results, Nicolas Goaziou, 2011/06/23
- Re: [O] [babel] using #+call for inline results, chris . m . malone, 2011/06/23
- Re: [O] [babel] using #+call for inline results,
Eric S Fraga <=
- Re: [O] [babel] using #+call for inline results, Nicolas Goaziou, 2011/06/23
- Re: [O] [babel] using #+call for inline results, Eric S Fraga, 2011/06/24
- Re: [O] [babel] using #+call for inline results, Christian Moe, 2011/06/23
- Re: [O] [babel] using #+call for inline results, Eric Schulte, 2011/06/24
- Re: [O] [babel] using #+call for inline results, Eric S Fraga, 2011/06/25
- Re: [O] [babel] using #+call for inline results, Christian Moe, 2011/06/26
- Re: [O] [babel] using #+call for inline results, Eric Schulte, 2011/06/26
- Re: [O] [babel] using #+call for inline results, Christian Moe, 2011/06/27
- Re: [O] [babel] using #+call for inline results, Eric Schulte, 2011/06/27
- Re: [O] [babel] using #+call for inline results, Christian Moe, 2011/06/27