emacs-orgmode
[Top][All Lists]
Advanced

[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)

`

reply via email to

 [Prev in Thread] Current Thread [Next in Thread]