Leo Alekseyev dnqu...@gmail.com writes:
On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote:
On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
Rick Frankel r...@rickster.com writes:
Turns out it was not that difficult to change this behavior. You and
Leo are
On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote:
On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
Rick Frankel r...@rickster.com writes:
Turns out it was not that difficult to change this behavior. You and
Leo are both correct that in-buffer-order
Therefore, when executing an entire buffer, there is no way to have
the execution of a call block dependent on the prior execution of a
source block.
It would be better to make the dependency explicit by passing the
results of the call line as a (potentially unused) variable to the code
On Thu, Jan 12, 2012 at 04:35:31PM -0600, Leo Alekseyev wrote:
Therefore, when executing an entire buffer, there is no way to have
the execution of a call block dependent on the prior execution of a
source block.
It would be better to make the dependency explicit by passing the
Rick Frankel r...@rickster.com writes:
On Thu, Jan 12, 2012 at 04:35:31PM -0600, Leo Alekseyev wrote:
Therefore, when executing an entire buffer, there is no way to have
the execution of a call block dependent on the prior execution of a
source block.
It would be better to make the
On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote:
Rick Frankel r...@rickster.com writes:
Turns out it was not that difficult to change this behavior. You and
Leo are both correct that in-buffer-order evaluation is more natural and
expected than the previous behavior. I've just
There is a problem with the order of execution of interspersed source
and call blocks will not be executed in order because of the way
org-babel-execute-buffer is written (first all the source blocks, then
all the call blocks).
Therefore, when executing an entire buffer, there is no way to have
