[babel] using #+call for inline results

[babel] using #+call for inline results

[Eric S Fraga]

Hello,

I have been playing with org babel for putting results inline within an
exported latex file.  A simple example is here:

--8<---------------cut here---------------start------------->8---
* testing inline evaluation of babel source blocks
  
  #+srcname: benzene-chlorobenzene-relative-volatility
  #+begin_src octave :exports none :results output raw :var T=25
format bank
pb = 10^(6.89272 - 1203.531/(T+219.888));
pc = 10^(7.10690 - 1500.0  /(T+224.000));
alpha = pb/pc;
disp(alpha)
  #+end_src

  1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\): 
     #+call: benzene-chlorobenzene-relative-volatility[:results output raw](T=25) :exports results

  2. Compare this to the value we get at 50 \(^{\circ}C\):
     #+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results 

  3. Next we use this value to draw an equilibrium curve.
      
--8<---------------cut here---------------end--------------->8---

If I evaluate the code block, I get what I expect:

,----
|   #+results: benzene-chlorobenzene-relative-volatility
|   7.86
`----

However, when I export the file, the #+call lines get wrapped in a
verbatim environment regardless of what or where I specify for
the :results header arguments.  E.g.:

,----
| \begin{enumerate}
| \item The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\): 
| 
| 
| \begin{verbatim}
|       7.86
| \end{verbatim}
| 
| \item Compare this to the value we get at 50 \(^{\circ}C\):
| 
| 
| \begin{verbatim}
|       6.32
| \end{verbatim}
`----

What am I doing wrong?  I have tried various permutations of the
placement of the :results header and various options for it but do not
seem to have hit on the right combination.

Ideally, I would like the number to appear completely inline with the
text the precedes and follows the #+call statement.  I would prefer to
not have a new paragraph started, for instance.

On a related note, although the manual seems to indicate that "raw" and
"org" are synonymous, they behave differently when evaluating a code
block with the latter encapsulating the output within #+begin_org
and #+end_org.  The behaviour is fine but maybe the documentation,
assuming I have understand things correctly, should be changed to
reflect the difference in behaviour?

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.418.ge860.dirty)

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

[Eric Schulte]

Hi Eric,

So the problem is that the results are inserted as a separate block,
when you want them to be inserted inline?  If so perhaps using an
"inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
would result in the desired behavior.

Please let me know if I've misunderstood the question.

Best -- Eric

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Hello,
>
> I have been playing with org babel for putting results inline within an
> exported latex file.  A simple example is here:
>
> * testing inline evaluation of babel source blocks
>   
>   #+srcname: benzene-chlorobenzene-relative-volatility
>   #+begin_src octave :exports none :results output raw :var T=25
> format bank
> pb = 10^(6.89272 - 1203.531/(T+219.888));
> pc = 10^(7.10690 - 1500.0  /(T+224.000));
> alpha = pb/pc;
> disp(alpha)
>   #+end_src
>
>   1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\): 
>      #+call: benzene-chlorobenzene-relative-volatility[:results output raw](T=25) :exports results
>
>   2. Compare this to the value we get at 50 \(^{\circ}C\):
>      #+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results 
>
>   3. Next we use this value to draw an equilibrium curve.
>       
>
> If I evaluate the code block, I get what I expect:
>
> ,----
> |   #+results: benzene-chlorobenzene-relative-volatility
> |   7.86
> `----
>
> However, when I export the file, the #+call lines get wrapped in a
> verbatim environment regardless of what or where I specify for
> the :results header arguments.  E.g.:
>
> ,----
> | \begin{enumerate}
> | \item The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\): 
> | 
> | 
> | \begin{verbatim}
> |       7.86
> | \end{verbatim}
> | 
> | \item Compare this to the value we get at 50 \(^{\circ}C\):
> | 
> | 
> | \begin{verbatim}
> |       6.32
> | \end{verbatim}
> `----
>
> What am I doing wrong?  I have tried various permutations of the
> placement of the :results header and various options for it but do not
> seem to have hit on the right combination.
>
> Ideally, I would like the number to appear completely inline with the
> text the precedes and follows the #+call statement.  I would prefer to
> not have a new paragraph started, for instance.
>
> On a related note, although the manual seems to indicate that "raw" and
> "org" are synonymous, they behave differently when evaluating a code
> block with the latter encapsulating the output within #+begin_org
> and #+end_org.  The behaviour is fine but maybe the documentation,
> assuming I have understand things correctly, should be changed to
> reflect the difference in behaviour?
>
> Thanks,
> eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Juan Pechiar]

Hi,

The documentation for #+call is rather confusing:

  It is also possible to evaluate named code blocks from anywhere in
  an Org-mode buffer or an Org-mode table. #+call (or synonymously
  #+function or #+lob) lines can be used to remotely execute code
  blocks...

Because aparently #+call only works on on a line by itself. Check the
following in ob-lob.el:

#+begin_src emacs-lisp
  (defconst org-babel-lob-one-liner-regexp
  (concat
   "^\\([ \t]*\\)#\\+\\(?:"
   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
   "\\):[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
   "\(\\([^\n]*\\)\)\\(\\[.+\\]\\|\\)[ \t]*\\([^\n]*\\)")
  "Regexp to match calls to predefined source block functions.")
#+end_src

This only matches whitespace at the beginning of line followed by
#+call (or lob or function), unlike the embedded calls of the form
src_<language>{body} which can be inlined.

Regards,
.j.

On Wed, Jun 22, 2011 at 12:07:57PM +0100, Eric S Fraga wrote:
> I have been playing with org babel for putting results inline within an
> exported latex file.  A simple example is here:
>
> --8<---------------cut here---------------start------------->8---
> * testing inline evaluation of babel source blocks
>
>   #+srcname: benzene-chlorobenzene-relative-volatility
>   #+begin_src octave :exports none :results output raw :var T=25
> format bank
> pb = 10^(6.89272 - 1203.531/(T+219.888));
> pc = 10^(7.10690 - 1500.0  /(T+224.000));
> alpha = pb/pc;
> disp(alpha)
>   #+end_src
>
>   1. The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\):
>      #+call: benzene-chlorobenzene-relative-volatility[:results output raw](T=25) :exports results
>
>   2. Compare this to the value we get at 50 \(^{\circ}C\):
>      #+call: benzene-chlorobenzene-relative-volatility(T=50) :exports results
>
>   3. Next we use this value to draw an equilibrium curve.
>
> --8<---------------cut here---------------end--------------->8---
>
> If I evaluate the code block, I get what I expect:
>
> ,----
> |   #+results: benzene-chlorobenzene-relative-volatility
> |   7.86
> `----
>
> However, when I export the file, the #+call lines get wrapped in a
> verbatim environment regardless of what or where I specify for
> the :results header arguments.  E.g.:
>
> ,----
> | \begin{enumerate}
> | \item The first step is to evaluate the relative volatility at \(T=25 ^{\circ} C\):
> |
> |
> | \begin{verbatim}
> |       7.86
> | \end{verbatim}
> |
> | \item Compare this to the value we get at 50 \(^{\circ}C\):
> |
> |
> | \begin{verbatim}
> |       6.32
> | \end{verbatim}
> `----
>
> What am I doing wrong?  I have tried various permutations of the
> placement of the :results header and various options for it but do not
> seem to have hit on the right combination.
>
> Ideally, I would like the number to appear completely inline with the
> text the precedes and follows the #+call statement.  I would prefer to
> not have a new paragraph started, for instance.
>
> On a related note, although the manual seems to indicate that "raw" and
> "org" are synonymous, they behave differently when evaluating a code
> block with the latter encapsulating the output within #+begin_org
> and #+end_org.  The behaviour is fine but maybe the documentation,
> assuming I have understand things correctly, should be changed to
> reflect the difference in behaviour?
>
> Thanks,
> eric
>

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

[Eric S Fraga]

Eric Schulte <schulte.eric@gmail.com> writes:

> Hi Eric,

Hi Eric!  ;-)

> So the problem is that the results are inserted as a separate block,
> when you want them to be inserted inline?  If so perhaps using an
> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
> would result in the desired behavior.
>
> Please let me know if I've misunderstood the question.

Yes and no.  I *do* want the effect that is achieved by using an inline
block but I do *not* want to write the whole block inline as that can be
difficult to do or, at the very best, hard to read even if possible... I
would like to invoke/evaluate, inline, a particular source code block
with a specific value of an argument.

From the documentation, I don't see how to "call" a src block inline.
That's why I thought of using =#+call=.  Am I missing something?

Thanks,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.418.ge860.dirty)

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

[Eric Schulte]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Hi Eric,
>
> Hi Eric!  ;-)
>
>> So the problem is that the results are inserted as a separate block,
>> when you want them to be inserted inline?  If so perhaps using an
>> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
>> would result in the desired behavior.
>>
>> Please let me know if I've misunderstood the question.
>
> Yes and no.  I *do* want the effect that is achieved by using an inline
> block but I do *not* want to write the whole block inline

I find the following pattern

  #+source: big-block
  #+begin_src emacs-lisp :exports none
    "something complex"
  #+end_src

  Here is some text with src_emacs-lisp[:var it=big-block]{it} in the
  middle.

to be helpful in these situations.

> as that can be difficult to do or, at the very best, hard to read even
> if possible... I would like to invoke/evaluate, inline, a particular
> source code block with a specific value of an argument.
>
> From the documentation, I don't see how to "call" a src block inline.
> That's why I thought of using =#+call=.  Am I missing something?
>

nope, there is no way to issue an in-line call, although maybe this
wouldn't be the worst idea if only for the added brevity over an inline
code block.

I'll put it on my long-term low-priority stack. :)

Cheers -- Eric

>
> Thanks,
> eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

Eric Schulte <schulte.eric@gmail.com> writes:

[...]

>> Yes and no.  I *do* want the effect that is achieved by using an inline
>> block but I do *not* want to write the whole block inline
>
> I find the following pattern
>
>   #+source: big-block
>   #+begin_src emacs-lisp :exports none
>     "something complex"
>   #+end_src
>
>   Here is some text with src_emacs-lisp[:var it=big-block]{it} in the
>   middle.
>
> to be helpful in these situations.

Okay, this is very useful!  It's difficult to get this working with
Octave but I think I have managed it.  It also doesn't allow for
parametrised calls to the source code block but that's easy to simulate
with a two level approach, I think.

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.

[...]

> nope, there is no way to issue an in-line call, although maybe this
> wouldn't be the worst idea if only for the added brevity over an inline
> code block.
>
> I'll put it on my long-term low-priority stack. :)

Brilliant.  Low priority is perfectly fine.  A solution is possible as
it stands and that's what matters!

Thanks,
eric

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: inline babel call --]
[-- Type: text/org, Size: 1024 bytes --]

#+ -*- org-confirm-babel-evaluate: nil; -*-

* testing inline evaluation of babel source blocks

  #+tblname: benzene-chlorobenzene-antoine-coefficients
  | Species       |       A |        B |       C |
  |---------------+---------+----------+---------|
  | benzene       | 6.89272 | 1203.531 | 219.888 |
  | chlorobenzene | 7.10690 |   1500.0 |     224 |

  #+srcname: benzene-chlorobenzene-relative-volatility
  #+begin_src octave :exports none :results value :var T=25 :var coeff=benzene-chlorobenzene-antoine-coefficients[2:-1,1:-1]
format bank
b=1; # row indices
c=2;
A=1; # column indices
B=2;
C=3;
for i=1:2, p(i) = 10^(coeff(i,A) - coeff(i,B)/(T+coeff(i,C))); endfor
p(b)/p(c)
  #+end_src

  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.

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]


-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.421.ge734e)

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

[Christian Moe]

+1 for inline calls. No hurry, though.

Yours,
Christian

On 6/23/11 7:32 AM, Eric Schulte wrote:
> Eric S Fraga<e.fraga@ucl.ac.uk>  writes:
>
>> Eric Schulte<schulte.eric@gmail.com>  writes:
>>
>>> Hi Eric,
>>
>> Hi Eric!  ;-)
>>
>>> So the problem is that the results are inserted as a separate block,
>>> when you want them to be inserted inline?  If so perhaps using an
>>> "inline" block http://orgmode.org/manual/Structure-of-code-blocks.html
>>> would result in the desired behavior.
>>>
>>> Please let me know if I've misunderstood the question.
>>
>> Yes and no.  I *do* want the effect that is achieved by using an inline
>> block but I do *not* want to write the whole block inline
>
> I find the following pattern
>
>    #+source: big-block
>    #+begin_src emacs-lisp :exports none
>      "something complex"
>    #+end_src
>
>    Here is some text with src_emacs-lisp[:var it=big-block]{it} in the
>    middle.
>
> to be helpful in these situations.
>
>> as that can be difficult to do or, at the very best, hard to read even
>> if possible... I would like to invoke/evaluate, inline, a particular
>> source code block with a specific value of an argument.
>>
>>  From the documentation, I don't see how to "call" a src block inline.
>> That's why I thought of using =#+call=.  Am I missing something?
>>
>
> nope, there is no way to issue an in-line call, although maybe this
> wouldn't be the worst idea if only for the added brevity over an inline
> code block.
>
> I'll put it on my long-term low-priority stack. :)
>
> Cheers -- Eric
>
>>
>> Thanks,
>> eric
>

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

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> 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,

-- 
Nicolas Goaziou

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

[chris.m.malone]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

I have been following this thread with interest. When I export Eric's  
babelcall.org, the result of the octave calculation is =nil= in both cases.  
Is this the expected behaviour? I can confirm Nicolas' observations as well.

Chris
On Jun 23, 2011 9:49am, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,



> Eric S Fraga e.fraga@ucl.ac.uk> 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,



> --

> Nicolas Goaziou




[-- Attachment #2: Type: text/html, Size: 1240 bytes --]

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

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> 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)

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

[Nicolas Goaziou]

Eric S Fraga <e.fraga@ucl.ac.uk> 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

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

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> 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*

Interesting.  What do you get?


[...]

> Well, all this babbling doesn't quite help to solve the issue at
> hand...

but thanks for the explanation: the processing is sort of what I
expected you were having to do.  Please don't worry too much about this
particular use case as it is not critical!

Thanks again,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.418.ge860.dirty)

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

[Eric Schulte]

Christian Moe <mail@christianmoe.com> writes:

> +1 for inline calls. No hurry, though.
>

I've just pushed up an implementation for inline call blocks, the new
syntax is described in the documentation but a simple example is below.

    #+source: square
    #+begin_src emacs-lisp :var it=0
      (* it it)
    #+end_src

    Here is a call_square(it=4) stuck in the middle of some prose.

Please let me know how it works and if you have any problems or
recommendations.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric S Fraga]

Eric Schulte <schulte.eric@gmail.com> writes:

> Christian Moe <mail@christianmoe.com> writes:
>
>> +1 for inline calls. No hurry, though.
>>
>
> I've just pushed up an implementation for inline call blocks, the new
> syntax is described in the documentation but a simple example is below.
>
>     #+source: square
>     #+begin_src emacs-lisp :var it=0
>       (* it it)
>     #+end_src
>
>     Here is a call_square(it=4) stuck in the middle of some prose.
>
> Please let me know how it works and if you have any problems or
> recommendations.
>
> Cheers -- Eric

Eric,

I haven't done much testing but it does seem to work very nicely and, in
fact, doesn't have the problem I had with using src_xxx{} in a list.

Brilliant!

Many thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.443.gf4a7e.dirty)

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

[Christian Moe]

Hi, Eric,

Very nice, thanks!

I note the turnover on your long-term low-priority stack is about two 
days.
:)

But I seem to have a problem (running your example):

Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let 
((it (match-string a))) (if (= (length it) 0) (match-string b) it))))
   (nonempty (a b) (let (...) (if ... ... it)))()
   org-babel-lob-get-info()
   org-babel-lob-execute-maybe()
   org-babel-execute-maybe()
   org-babel-execute-safely-maybe()
   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
   org-ctrl-c-ctrl-c(nil)
   call-interactively(org-ctrl-c-ctrl-c nil nil)

Yours,
Christian


On 6/25/11 12:36 AM, Eric Schulte wrote:
> Christian Moe<mail@christianmoe.com>  writes:
>
>> +1 for inline calls. No hurry, though.
>>
>
> I've just pushed up an implementation for inline call blocks, the new
> syntax is described in the documentation but a simple example is below.
>
>      #+source: square
>      #+begin_src emacs-lisp :var it=0
>        (* it it)
>      #+end_src
>
>      Here is a call_square(it=4) stuck in the middle of some prose.
>
> Please let me know how it works and if you have any problems or
> recommendations.
>
> Cheers -- Eric
>

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

[Eric Schulte]

>
> But I seem to have a problem (running your example):
>
> Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let
> ((it (match-string a))) (if (= (length it) 0) (match-string b) it))))
>   (nonempty (a b) (let (...) (if ... ... it)))()
>   org-babel-lob-get-info()
>   org-babel-lob-execute-maybe()
>   org-babel-execute-maybe()
>   org-babel-execute-safely-maybe()
>   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
>   org-ctrl-c-ctrl-c(nil)
>   call-interactively(org-ctrl-c-ctrl-c nil nil)
>

I believe this is due to my forgetting to require 'cl at compile time.
I've just pushed up a fix, please let me know if the problem persists.

Thanks -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Christian Moe]

Fixed, thanks. I should have guessed that might be it.

Evaluating inline calls now works, but there are some ramifications 
for output and export that I hadn't thought about when I seconded the 
request.


* Export

The call itself should not be exported, but I'm seeing:

: <p>
: Here is a call<sub>square</sub>(it=4) <code>16</code> stuck in the 
middle of some prose.
: </p>


* Output

To get rid of the literal equals-signs, I try:

: Here is a call_square(it=4)[:results raw] stuck in the middle of 
some prose.

I expect to get the result inline, but instead it comes as a normal 
call results block (aligned with the call):

:          #+results: square(it=4)
:          16


Yours,
Christian

On 6/27/11 2:14 AM, Eric Schulte wrote:
>>
>> But I seem to have a problem (running your example):
>>
>> Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let
>> ((it (match-string a))) (if (= (length it) 0) (match-string b) it))))
>>    (nonempty (a b) (let (...) (if ... ... it)))()
>>    org-babel-lob-get-info()
>>    org-babel-lob-execute-maybe()
>>    org-babel-execute-maybe()
>>    org-babel-execute-safely-maybe()
>>    run-hook-with-args-until-success(org-babel-execute-safely-maybe)
>>    org-ctrl-c-ctrl-c(nil)
>>    call-interactively(org-ctrl-c-ctrl-c nil nil)
>>
>
> I believe this is due to my forgetting to require 'cl at compile time.
> I've just pushed up a fix, please let me know if the problem persists.
>
> Thanks -- Eric
>

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

[Eric S Fraga]

Eric Schulte <schulte.eric@gmail.com> writes:
>
> I've just pushed up an implementation for inline call blocks, the new
> syntax is described in the documentation but a simple example is below.
>
>     #+source: square
>     #+begin_src emacs-lisp :var it=0
>       (* it it)
>     #+end_src
>
>     Here is a call_square(it=4) stuck in the middle of some prose.
>
> Please let me know how it works and if you have any problems or
> recommendations.
>
> Cheers -- Eric

Eric,

this was working on Friday but seems to have stopped working for me now
completely.  For instance, your snippet above exports as

--8<---------------cut here---------------start------------->8---
\lstset{language=Lisp}
\begin{lstlisting}
(* it it)
\end{lstlisting}




  Here is a call$_{\mathrm{square}}$(it=4) stuck in the middle of some prose.
--8<---------------cut here---------------end--------------->8---

I do not believe I have changed anything in my settings...

I do note from the git log that you have made quite a few changes.  Has
some setting crept in that I need to configure?

Also, I note from the comments that you expect the inline call to be
whitespace delimited.  I haven't tested this but, just in case, could I
request that the delimiting be either whitespace or punctuation?  There
are cases where I would like the inline evaluation to be at the end of a
sentence, for instance, or even something like:

  25^2=call_square(it=25)

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.461.g6d18)

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

[Eric Schulte]

Christian Moe <mail@christianmoe.com> writes:

> Fixed, thanks. I should have guessed that might be it.
>
> Evaluating inline calls now works, but there are some ramifications
> for output and export that I hadn't thought about when I seconded the
> request.
>
>
> * Export
>
> The call itself should not be exported, but I'm seeing:
>
> : <p>
> : Here is a call<sub>square</sub>(it=4) <code>16</code> stuck in the
> middle of some prose.
> : </p>
>
>
> * Output
>
> To get rid of the literal equals-signs, I try:
>
> : Here is a call_square(it=4)[:results raw] stuck in the middle of
> some prose.
>
> I expect to get the result inline, but instead it comes as a normal
> call results block (aligned with the call):
>
> :          #+results: square(it=4)
> :          16
>

Hi Christian,

Thanks for sharing these issues, it appears I messed some functionality
up with some of my recent changes.  I believe that I have fixed these
issues.  The following examples should now all export as described.

--8<---------------cut here---------------start------------->8---
The following exports as a normal call line
#+call: double(it=1)

Now here is an inline call call_double(it=1) stuck in the middle of
some prose.

This one should not be exported =call_double(it=2)= because it is
quoted.

Finally this next one should export, even though it starts a line
call_double(it=3) because sometimes inline blocks fold with a
paragraph.

And, a call with raw results call_double(4)[:results raw] should not
have quoted results.
--8<---------------cut here---------------end--------------->8---

Please let me know if you experience any more problems, and thanks for
helping to get this sorted before the impending release!

Cheers -- Eric

>
>
> Yours,
> Christian
>
> On 6/27/11 2:14 AM, Eric Schulte wrote:
>>>
>>> But I seem to have a problem (running your example):
>>>
>>> Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let
>>> ((it (match-string a))) (if (= (length it) 0) (match-string b) it))))
>>>    (nonempty (a b) (let (...) (if ... ... it)))()
>>>    org-babel-lob-get-info()
>>>    org-babel-lob-execute-maybe()
>>>    org-babel-execute-maybe()
>>>    org-babel-execute-safely-maybe()
>>>    run-hook-with-args-until-success(org-babel-execute-safely-maybe)
>>>    org-ctrl-c-ctrl-c(nil)
>>>    call-interactively(org-ctrl-c-ctrl-c nil nil)
>>>
>>
>> I believe this is due to my forgetting to require 'cl at compile time.
>> I've just pushed up a fix, please let me know if the problem persists.
>>
>> Thanks -- Eric
>>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>> I've just pushed up an implementation for inline call blocks, the new
>> syntax is described in the documentation but a simple example is below.
>>
>>     #+source: square
>>     #+begin_src emacs-lisp :var it=0
>>       (* it it)
>>     #+end_src
>>
>>     Here is a call_square(it=4) stuck in the middle of some prose.
>>
>> Please let me know how it works and if you have any problems or
>> recommendations.
>>
>> Cheers -- Eric
>
> Eric,
>
> this was working on Friday but seems to have stopped working for me now
> completely.  For instance, your snippet above exports as
>
> \lstset{language=Lisp}
> \begin{lstlisting}
> (* it it)
> \end{lstlisting}
>
>
>
>
>   Here is a call$_{\mathrm{square}}$(it=4) stuck in the middle of some prose.
>
> I do not believe I have changed anything in my settings...
>
> I do note from the git log that you have made quite a few changes.  Has
> some setting crept in that I need to configure?
>

Hmm, have you updated Org-mode in the last hour/minutes, there have
indeed been a number of changes recently.  I believe that the above
should be working now, without requiring any special configuration.

>
> Also, I note from the comments that you expect the inline call to be
> whitespace delimited.  I haven't tested this but, just in case, could I
> request that the delimiting be either whitespace or punctuation?

As this behaves currently there need only be whitespace _before_ the
inline call line, not after, so most normal punctuation usage should
work.  For example the following exports as expected on my system.

--8<---------------cut here---------------start------------->8---
#+source: square
#+begin_src emacs-lisp :var it=0
  (* it it)
#+end_src

Here is a call_square(it=4), stuck in the middle of some prose.
--8<---------------cut here---------------end--------------->8---

> There are cases where I would like the inline evaluation to be at the
> end of a sentence, for instance, or even something like:
>
>   25^2=call_square(it=25)
>

hmm, good example, so what set of characters should be allowed to prefix
and postfix such a block?  For example, = before should export however =
both before and after would be a literal example.

Cheers -- Eric

>
> Thanks,
> eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Christian Moe]

Hi,

Yes, these all checked out (assuming you meant the second one /should/ 
be exported -- as quoted code -- but not evaluated).

This is a nice addition, and rather cleaner and more intuitive than 
the workarounds I've been playing with. (Faking an inline call to 
block A with an inline src block B that takes a variable from calling 
A in the header args, and shortening it with a macro that expands to B...)

Yours,
Christian

On 6/27/11 7:43 PM, Eric Schulte wrote:
>  I believe that I have fixed these
> issues.  The following examples should now all export as described.
>
> --8<---------------cut here---------------start------------->8---
> The following exports as a normal call line
> #+call: double(it=1)
>
> Now here is an inline call call_double(it=1) stuck in the middle of
> some prose.
>
> This one should not be exported =call_double(it=2)= because it is
> quoted.
>
> Finally this next one should export, even though it starts a line
> call_double(it=3) because sometimes inline blocks fold with a
> paragraph.
>
> And, a call with raw results call_double(4)[:results raw] should not
> have quoted results.
> --8<---------------cut here---------------end--------------->8---

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

[Sebastien Vauban]

Hi Erics and Christian,

Eric Schulte wrote:
> Thanks for sharing these issues, it appears I messed some functionality
> up with some of my recent changes.  I believe that I have fixed these
> issues.  The following examples should now all export as described.
>
> The following exports as a normal call line
> #+call: double(it=1)
>
> Now here is an inline call call_double(it=1) stuck in the middle of
> some prose.
>
> This one should not be exported =call_double(it=2)= because it is
> quoted.
>
> Finally this next one should export, even though it starts a line
> call_double(it=3) because sometimes inline blocks fold with a
> paragraph.
>
> And, a call with raw results call_double(4)[:results raw] should not
> have quoted results.
>
> Please let me know if you experience any more problems, and thanks for
> helping to get this sorted before the impending release!

I did test, and it seems to work for me with a Org pulled 30 mins ago:

    http://i.imgur.com/WhaVs.png

Well, I have many other problems with this version (such as speed commands not
working anymore, yasnippet expansion not working anymore on TAB, some files
which say they're not in Org-agenda-files, etc.) but that's another story.

About this, my only weirdness is that I had to confirm 12 times (yes, 12!)
that I wanted to execute the calls.

I have this in my emacs config file for months

        ;; don't be prompted on every code block evaluation
        (setq org-confirm-babel-evaluate nil)

... has this var become a local file variable?

Last thing: the questions in the echo area sometimes display the block name in
parentheses, sometimes not...

- "Evaluate this emacs-lisp code block (square) on your system? (yes or no)"
- "Evaluate this emacs-lisp code block on your system? (yes or no)"

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Eric Schulte]

>
> Well, I have many other problems with this version (such as speed commands not
> working anymore, yasnippet expansion not working anymore on TAB, some files
> which say they're not in Org-agenda-files, etc.) but that's another story.
>

I don't understand, are you saying that all of the above problems are
caused by the introduction of inline call lines?  I have not experienced
any of these problems.

>
> About this, my only weirdness is that I had to confirm 12 times (yes, 12!)
> that I wanted to execute the calls.
>
> I have this in my emacs config file for months
>
>         ;; don't be prompted on every code block evaluation
>         (setq org-confirm-babel-evaluate nil)
>
> ... has this var become a local file variable?
>

This has not become a buffer local variable and I can not reproduce your
problem, could you please submit a minimal configuration with which I
can reproduce this problem.

>
> Last thing: the questions in the echo area sometimes display the block name in
> parentheses, sometimes not...
>
> - "Evaluate this emacs-lisp code block (square) on your system? (yes or no)"
> - "Evaluate this emacs-lisp code block on your system? (yes or no)"
>

When the code block has a name, the name is shown in parens, when the
code block is not named no name is shown.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> Well, I have many other problems with this version (such as speed commands
>> not working anymore, yasnippet expansion not working anymore on TAB, some
>> files which say they're not in Org-agenda-files, etc.) but that's another
>> story.
>
> I don't understand, are you saying that all of the above problems are caused
> by the introduction of inline call lines? I have not experienced any of
> these problems.

No, I just said I had many other little problems since the last git update.
Though, I did not know where they come from. Now, I am positive that it comes
from the LOB. See the ECM I sent yesterday, and the similar report done
yesterday by Darlan.

>> About this, my only weirdness is that I had to confirm 12 times (yes, 12!)
>> that I wanted to execute the calls.
>>
>> I have this in my emacs config file for months
>>
>>         ;; don't be prompted on every code block evaluation
>>         (setq org-confirm-babel-evaluate nil)
>>
>> ... has this var become a local file variable?
>
> This has not become a buffer local variable and I can not reproduce your
> problem, could you please submit a minimal configuration with which I
> can reproduce this problem.

When removing the Org file with the SQL code from my org-agenda-files, and
relaunching Emacs (on an updated git), I don't see that problem anymore...
Maybe related to the above problem, then.

>> Last thing: the questions in the echo area sometimes display the block name
>> in parentheses, sometimes not...
>>
>> - "Evaluate this emacs-lisp code block (square) on your system? (yes or no)"
>> - "Evaluate this emacs-lisp code block on your system? (yes or no)"
>
> When the code block has a name, the name is shown in parens, when the code
> block is not named no name is shown.

What I did not understand, is that these messages appeared when running the
example file I took, where only one block is defined, and that block is named.
Hence, I'd expect to always see the same message, with the block name in
parentheses.

Though, as I don't have to confirm anymore (the symptom disappeared), we can
put this in the fridge... but for the problem with the LOB file (see
http://www.mail-archive.com/emacs-orgmode-mXXj517/zsQ@public.gmane.org/msg43083.html).

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Eric S Fraga]

Eric Schulte <schulte.eric@gmail.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:

[...]

>> this was working on Friday but seems to have stopped working for me now
>> completely.  For instance, your snippet above exports as
>
> Hmm, have you updated Org-mode in the last hour/minutes, there have
> indeed been a number of changes recently.  I believe that the above
> should be working now, without requiring any special configuration.

Sorry for the delay in getting back to you: work sometimes interrupts
and, just to add a little excitement in my life, we had a major lighting
storm yesterday which blew out my home network!  :( But I can't
complain: a house down the street caught fire due to the same storm.
It's a lot cheaper and slightly less inconvenient to buy a new router
than rebuild a house...

In any case, everything seems to be working just fine now!

>> Also, I note from the comments that you expect the inline call to be
>> whitespace delimited.  I haven't tested this but, just in case, could I
>> request that the delimiting be either whitespace or punctuation?
>
> As this behaves currently there need only be whitespace _before_ the
> inline call line, not after, so most normal punctuation usage should
> work.  

Yes, that's fine.  Thanks for the clarification!

[...]

>> There are cases where I would like the inline evaluation to be at the
>> end of a sentence, for instance, or even something like:
>
>>
>>   25^2=call_square(it=25)
>>
>
> hmm, good example, so what set of characters should be allowed to prefix
> and postfix such a block?  For example, = before should export however =
> both before and after would be a literal example.

I don't know if you've done anything about this but I think it is
probably not worth worrying about these edge cases.  It probably opens
up a can of worms and requiring a white space before the inline call is
fine with me.

Thanks again,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.510.g56080)

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

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>>> Well, I have many other problems with this version (such as speed commands
>>> not working anymore, yasnippet expansion not working anymore on TAB, some
>>> files which say they're not in Org-agenda-files, etc.) but that's another
>>> story.
>>
>> I don't understand, are you saying that all of the above problems are caused
>> by the introduction of inline call lines? I have not experienced any of
>> these problems.
>
> No, I just said I had many other little problems since the last git update.
> Though, I did not know where they come from. Now, I am positive that it comes
> from the LOB. See the ECM I sent yesterday, and the similar report done
> yesterday by Darlan.
>

Hi Seb,

I don't know what you are referencing above, but if the new LOB behavior
is causing problems then I certainly want to help resolve them.  Can you
link me to the "ECM" you mentioned, and to Darlan's report?

>
>>> About this, my only weirdness is that I had to confirm 12 times (yes, 12!)
>>> that I wanted to execute the calls.
>>>
>>> I have this in my emacs config file for months
>>>
>>>         ;; don't be prompted on every code block evaluation
>>>         (setq org-confirm-babel-evaluate nil)
>>>
>>> ... has this var become a local file variable?
>>
>> This has not become a buffer local variable and I can not reproduce your
>> problem, could you please submit a minimal configuration with which I
>> can reproduce this problem.
>
> When removing the Org file with the SQL code from my org-agenda-files, and
> relaunching Emacs (on an updated git), I don't see that problem anymore...
> Maybe related to the above problem, then.
>

Hmm, could you send me a copy (or minimal subset) of this offending
Org-mode file that causes the multiple prompts?  Are you loading this
file using `org-babel-lob-ingest'?

>
>>> Last thing: the questions in the echo area sometimes display the block name
>>> in parentheses, sometimes not...
>>>
>>> - "Evaluate this emacs-lisp code block (square) on your system? (yes or no)"
>>> - "Evaluate this emacs-lisp code block on your system? (yes or no)"
>>
>> When the code block has a name, the name is shown in parens, when the code
>> block is not named no name is shown.
>
> What I did not understand, is that these messages appeared when running the
> example file I took, where only one block is defined, and that block is named.
> Hence, I'd expect to always see the same message, with the block name in
> parentheses.
>
> Though, as I don't have to confirm anymore (the symptom disappeared), we can
> put this in the fridge... but for the problem with the LOB file (see
> thtp://www.mail-archive.com/emacs-orgmode@gnu.org/msg43083.html).
>

Oh, I see, the file in question is mentioned in this linked email.  I
will take a look and see if I can reproduce locally.  Expect more from
me on this today.

Cheers -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Hi Seb,

I have attempted to reproduce the two problems I've seen mentioned,
specifically

1. repeated prompts to evaluate code when `org-confirm-babel-evaluate'
   is set to nil

2. Org-mode files not being seen with Org set as the major mode

I've used the following minimal configuration

[-- Attachment #2: seb.el --]
[-- Type: application/emacs-lisp, Size: 239 bytes --]

[-- Attachment #3: Type: text/plain, Size: 118 bytes --]

which adds the problematic Org-mode file you included in a recent email
(attached) into the list of org-agenda-files.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: seb.org --]
[-- Type: text/x-org, Size: 854 bytes --]

#+TITLE:     Babel ECM
#+DATE:      2011-06-28
#+DESCRIPTION: 
#+KEYWORDS: 
#+LANGUAGE:  en_US
#+LaTeX_CLASS: mcreport
#+LaTeX_CLASS_OPTIONS: (final)
#+BABEL:     :eval never :engine msosql :cmdline -S cauchy -U sa -P LpmdlP -d pfi-paiestag -n -w 700 :results output :exports both :noweb yes

* Introduction

This library is an extensible *collection of* ready-made *code blocks*
for handling common tasks.

* "Generic" Transact-SQL

** Add a column into a table

#+srcname: add-column-in-table[table, column, type, nullability]
#+begin_src sql
  -- add column `$column' [if column does not exist yet]
  IF NOT EXISTS [SELECT *
                 FROM INFORMATION_SCHEMA.COLUMNS
                 WHERE TABLE_NAME = '$table'
                 AND COLUMN_NAME = '$column']
  BEGIN
      ALTER TABLE $table
      ADD $column $type $nullability
  END
#+end_src

[-- Attachment #5: Type: text/plain, Size: 3482 bytes --]


I have been unable to reproduce either of the problems you described.
Could you start with these two files and build a minimal example
demonstrating the bug which can be started with something along the
lines of
: emacs -Q -l seb.el

Once I can observer the behavior then I should have a chance to fix it.

Thanks -- Eric

Eric Schulte <schulte.eric@gmail.com> writes:

> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>
>> Hi Eric,
>>
>> Eric Schulte wrote:
>>>> Well, I have many other problems with this version (such as speed commands
>>>> not working anymore, yasnippet expansion not working anymore on TAB, some
>>>> files which say they're not in Org-agenda-files, etc.) but that's another
>>>> story.
>>>
>>> I don't understand, are you saying that all of the above problems are caused
>>> by the introduction of inline call lines? I have not experienced any of
>>> these problems.
>>
>> No, I just said I had many other little problems since the last git update.
>> Though, I did not know where they come from. Now, I am positive that it comes
>> from the LOB. See the ECM I sent yesterday, and the similar report done
>> yesterday by Darlan.
>>
>
> Hi Seb,
>
> I don't know what you are referencing above, but if the new LOB behavior
> is causing problems then I certainly want to help resolve them.  Can you
> link me to the "ECM" you mentioned, and to Darlan's report?
>
>>
>>>> About this, my only weirdness is that I had to confirm 12 times (yes, 12!)
>>>> that I wanted to execute the calls.
>>>>
>>>> I have this in my emacs config file for months
>>>>
>>>>         ;; don't be prompted on every code block evaluation
>>>>         (setq org-confirm-babel-evaluate nil)
>>>>
>>>> ... has this var become a local file variable?
>>>
>>> This has not become a buffer local variable and I can not reproduce your
>>> problem, could you please submit a minimal configuration with which I
>>> can reproduce this problem.
>>
>> When removing the Org file with the SQL code from my org-agenda-files, and
>> relaunching Emacs (on an updated git), I don't see that problem anymore...
>> Maybe related to the above problem, then.
>>
>
> Hmm, could you send me a copy (or minimal subset) of this offending
> Org-mode file that causes the multiple prompts?  Are you loading this
> file using `org-babel-lob-ingest'?
>
>>
>>>> Last thing: the questions in the echo area sometimes display the block name
>>>> in parentheses, sometimes not...
>>>>
>>>> - "Evaluate this emacs-lisp code block (square) on your system? (yes or no)"
>>>> - "Evaluate this emacs-lisp code block on your system? (yes or no)"
>>>
>>> When the code block has a name, the name is shown in parens, when the code
>>> block is not named no name is shown.
>>
>> What I did not understand, is that these messages appeared when running the
>> example file I took, where only one block is defined, and that block is named.
>> Hence, I'd expect to always see the same message, with the block name in
>> parentheses.
>>
>> Though, as I don't have to confirm anymore (the symptom disappeared), we can
>> put this in the fridge... but for the problem with the LOB file (see
>> thtp://www.mail-archive.com/emacs-orgmode@gnu.org/msg43083.html).
>>
>
> Oh, I see, the file in question is mentioned in this linked email.  I
> will take a look and see if I can reproduce locally.  Expect more from
> me on this today.
>
> Cheers -- Eric
>
>>
>> Best regards,
>>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

[...]
>
> Sorry for the delay in getting back to you: work sometimes interrupts
> and, just to add a little excitement in my life, we had a major lighting
> storm yesterday which blew out my home network!  :( But I can't
> complain: a house down the street caught fire due to the same storm.
> It's a lot cheaper and slightly less inconvenient to buy a new router
> than rebuild a house...
>
> In any case, everything seems to be working just fine now!
>

Happy to hear you made it through the storm relatively unscathed.

[...]
>>> There are cases where I would like the inline evaluation to be at the
>>> end of a sentence, for instance, or even something like:
>>
>>>
>>>   25^2=call_square(it=25)
>>>
>>
>> hmm, good example, so what set of characters should be allowed to prefix
>> and postfix such a block?  For example, = before should export however =
>> both before and after would be a literal example.
>
> I don't know if you've done anything about this but I think it is
> probably not worth worrying about these edge cases.  It probably opens
> up a can of worms and requiring a white space before the inline call is
> fine with me.
>

This actually wasn't hard to implement, and the example you mentioned
above should be working now, at least according to the relevant portion
of the Org-mode test suite -- see "exporting an lob call line" in
org-mode/testing/examples/babel.org.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/