org-export-babel-evaluate and header arguments

org-export-babel-evaluate and header arguments

[Anthony Cowley]

If I have org-export-babel-evaluate set to nil, source blocks are not evaluated on export. However, if a source block has a :var header argument that calls another source block, I am prompted if the callee should be evaluated.

Given that the caller is not to be evaluated, I'm not sure I see a reason for the :var to be evaluated. Is there a way I can disable this argument evaluation?

My goal is quick exports, but in this case it actually seems like a bug since all of my code blocks are :session. If I give permission to evaluate the :var argument, it will result in an error since the session hasn't been updated with the evaluations of other source blocks.

Thanks,
Anthony

Re: org-export-babel-evaluate and header arguments

[Charles C. Berry]

On Wed, 9 Mar 2016, Anthony Cowley wrote:

>
> If I have org-export-babel-evaluate set to nil, source blocks are not 
> evaluated on export. However, if a source block has a :var header 
> argument that calls another source block, I am prompted if the callee 
> should be evaluated.
>
> Given that the caller is not to be evaluated, I'm not sure I see a 
> reason for the :var to be evaluated.

What gives here is that `org-babel-get-src-block-info' needs to develop 
all the header arguments regardless of evaluation of the code block, so 
:var gets handled.

> Is there a way I can disable this argument evaluation?

Something like:

 	:var a=(and org-export-babel-evaluate (org-sbe "abc"))


See C-h f org-sbe RET

HTH,

Chuck

Re: org-export-babel-evaluate and header arguments

[Anthony Cowley]

Charles C. Berry writes:

> On Wed, 9 Mar 2016, Anthony Cowley wrote:
>
>>
>> If I have org-export-babel-evaluate set to nil, source blocks are not 
>> evaluated on export. However, if a source block has a :var header 
>> argument that calls another source block, I am prompted if the callee 
>> should be evaluated.
>>
>> Given that the caller is not to be evaluated, I'm not sure I see a 
>> reason for the :var to be evaluated.
>
> What gives here is that `org-babel-get-src-block-info' needs to develop 
> all the header arguments regardless of evaluation of the code block, so 
> :var gets handled.
>
>> Is there a way I can disable this argument evaluation?
>
> Something like:
>
>  	:var a=(and org-export-babel-evaluate (org-sbe "abc"))
>
>
> See C-h f org-sbe RET
>
> HTH,
>
> Chuck

Thanks for the tip, Chuck!

This works out very well with one minor caveat:

Setting org-export-babel-evaluate to nil means that C-c C-c no longer properly evaluates a block with such a header. This means that exporting must be enabled during development.

Other than that little quibble, I've gotten this to work in both tiny tests and with complicated, slow to evaluate documents, so I'm pleased.

A minor note about org-sbe documentation is that header arguments need not be in a table, but should simply be passed as a single string as the first argument to org-sbe. This is inferable from the documentation, but a bit oblique.

Anthony

Re: org-export-babel-evaluate and header arguments

[Charles C. Berry]

On Thu, 10 Mar 2016, Anthony Cowley wrote:

>
> Charles C. Berry writes:
>
>> On Wed, 9 Mar 2016, Anthony Cowley wrote:
>>
>>>
>>> If I have org-export-babel-evaluate set to nil, source blocks are not
>>> evaluated on export. However, if a source block has a :var header
>>> argument that calls another source block, I am prompted if the callee
>>> should be evaluated.
[snip]
>>
>>> Is there a way I can disable this argument evaluation?
>>
>> Something like:
>>
>>  	:var a=(and org-export-babel-evaluate (org-sbe "abc"))

[snip]

>
> This works out very well with one minor caveat:
>
> Setting org-export-babel-evaluate to nil means that C-c C-c no longer 
> properly evaluates a block with such a header. This means that exporting 
> must be enabled during development.
>

Maybe you can get what you want by setting `:eval never-exports' for the 
buffer. See

 	(info "(org) exports")

 	(info "(org) Header arguments in Org mode properties")

HTH,

Chuck