Re: Babel CALL no longer produces HTML output

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Sat, 23 Jul 2016, Nicolas Goaziou wrote:

>> OTOH, inheriting :exports property may not be optimal. In particular,
>> ":exports code" for a Babel call is probably nonsensical. Perhaps
>> a solution would be to keep the current behaviour and make an exception
>> for :exports, which would always be `results' for Babel calls.
>>
>> WDYT?
>
> I think that would work well enough.

Funnily, that's what the previous evaluation process did.

I was confused by the "default" part in
`org-babel-default-lob-header-args'. I realize that this variable is no
replacement for `org-babel-default-header-args'. It permits to override
headers inherited from the source block instead.

This is now fixed. I updated variable docstring accordingly.

> Although I might quibble about what 'local' means here. If the src
> block is under a headline called XYZ with a `header-args' property of
> `:eval no' and the babel call is under headline ABC with no
> header-args property, I think some would expect the default to take
> precedence for calls under ABC over the property in XYZ.

The point is that a Babel call without any header argument or node
property defined at point of call should behave exactly as the src block
being called (minus the :exports behaviour, per above).

It seems logical to me that a source block that cannot be evaled cannot
be, by default, called either.

You may want to add (:eval . "yes") to
`org-babel-default-lob-header-args' if you disagree.

Regards,

-- 
Nicolas Goaziou