Re: [O] [babel] using #+call for inline results

[Nicolas Goaziou]

Eric S Fraga <address@hidden> 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