Babel CALL no longer produces HTML output

Babel CALL no longer produces HTML output

[Jarmo Hurri]

Greetings.

The Org example below used to work correctly when exported as HTML until
I pulled a newer version of Org from git. I am first going to include
the example here, and then explain the reasoning behind its structure.

=======================================================================
* Example
  
  This call here produced HTML output when exported as HTML until the
  newer versions of Org. Now it produces no HTML output whatsoever.

  #+CALL: rekursio-pystyviivat[:noweb yes]() :results html
  
  The following code blocks still work as expected.
  
  #+NAME: rekursio-pystyviivat-runko
  #+BEGIN_SRC processing :exports none
    if (viivoja == 0)
    return;

    line (x, 0, x, korkeus);
    piirraPystyviivat (viivoja - 1, x + 10, 0.9 * korkeus);
  #+END_SRC

  #+NAME: rekursio-pystyviivat
  #+BEGIN_SRC processing :exports code :noweb no
    void piirraPystyviivat (int viivoja, float x, float korkeus)
    {
      <<rekursio-pystyviivat-runko>>
    }

    void setup ()
    {
      size (600, 400);
      noLoop ();
    }

    void draw ()
    {
      piirraPystyviivat (50, 10, 350);
    }
  #+END_SRC
=======================================================================

In the example above I am playing with noweb to produce the following
_excellent_ teaching effect:

- the last Babel code block is what a student sees

- the student is supposed to replace
  <<rekursio-pystyviivat-runko>>
  with correct code, in this case the body of a recursive function

- the last block has ":noweb no" so that the missing part is not
  replaced by the correct solution

- in the CALL, however, noweb is set to yes so that noweb replacement is
  done, and the first block produces the correct output (in the case of
  Processing language, this is a picture)

I use this structure quite a bit in my material, which is finished
except for layout formatting. So I am going to be in trouble if I can no
longer get the logic to work in Org.

Jarmo

Re: Babel CALL no longer produces HTML output

[Christian Moe]

>   #+CALL: rekursio-pystyviivat[:noweb yes]() :results html

HTML blocks have been replaced with EXPORT blocks in recent Org. For
good reasons, I presume, but it takes some getting used to.

Try:

    #+CALL: rekursio-pystyviivat[:noweb yes]() :results export html

Yours,
Christian

Re: Babel CALL no longer produces HTML output

[Jarmo Hurri]

Christian Moe <mail@christianmoe.com> writes:

>>   #+CALL: rekursio-pystyviivat[:noweb yes]() :results html
>
> HTML blocks have been replaced with EXPORT blocks in recent Org. For
> good reasons, I presume, but it takes some getting used to.
>
> Try:
>
>     #+CALL: rekursio-pystyviivat[:noweb yes]() :results export html

Greetings Christian,

for some reason that did not improve the end result.

The funny thing is, if you press C-c C-c in the Org file at the location
of that CALL, it produces the correct HTML (try). But it is missing from
the automatically exported HTML file (try it too).

Jarmo

Re: Babel CALL no longer produces HTML output

[Charles C. Berry]

On Sat, 23 Jul 2016, Jarmo Hurri wrote:

>
> Greetings.
>
> The Org example below used to work correctly when exported as HTML until
> I pulled a newer version of Org from git. I am first going to include
> the example here, and then explain the reasoning behind its structure.
>

Commit dbb375f mades changes to the babel call handling.

IIUC, one result is that header args in the src block being called take 
precedence over default header args. More below.


> =======================================================================
> * Example
>
>  This call here produced HTML output when exported as HTML until the
>  newer versions of Org. Now it produces no HTML output whatsoever.
>
>  #+CALL: rekursio-pystyviivat[:noweb yes]() :results html
>

Try this:

#+CALL: rekursio-pystyviivat[:noweb yes :exports results]() :results html


>  The following code blocks still work as expected.
>

[snip]

Since you have `:exports code' here, that prevents the evaluation of the 
babel call above:


>  #+NAME: rekursio-pystyviivat
>  #+BEGIN_SRC processing :exports code :noweb no
>    void piirraPystyviivat (int viivoja, float x, float korkeus)
>    {
>      <<rekursio-pystyviivat-runko>>
>    }
>
>    void setup ()
>    {
>      size (600, 400);
>      noLoop ();
>    }
>
>    void draw ()
>    {
>      piirraPystyviivat (50, 10, 350);
>    }
>  #+END_SRC
> =======================================================================


I am not sure I find this new behavior to be an improvement.


Chuck

Re: Babel CALL no longer produces HTML output

[Nicolas Goaziou]

Hello,

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

> IIUC, one result is that header args in the src block being called take 
> precedence over default header args. More below.

[...]

> I am not sure I find this new behavior to be an improvement.

Having default header args to take precedence over local ones seems
counter-intuitive. It makes it harder to override them, and harder to
reason about the current active headers.

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?

Regards,

-- 
Nicolas Goaziou

Re: Babel CALL no longer produces HTML output

[Jarmo Hurri]

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

> On Sat, 23 Jul 2016, Jarmo Hurri wrote:
>> The Org example below used to work correctly when exported as HTML
>> until I pulled a newer version of Org from git. I am first going to
>> include the example here, and then explain the reasoning behind its
>> structure.
>>
>
> Commit dbb375f mades changes to the babel call handling.
>
> IIUC, one result is that header args in the src block being called
> take precedence over default header args. More below.
>
>
>> =======================================================================
>> * Example
>>
>>  This call here produced HTML output when exported as HTML until the
>>  newer versions of Org. Now it produces no HTML output whatsoever.
>>
>>  #+CALL: rekursio-pystyviivat[:noweb yes]() :results html
>>
>
> Try this:
>
> #+CALL: rekursio-pystyviivat[:noweb yes :exports results]() :results html

Yes! It works now, thank you very, very much. More below.

> Since you have `:exports code' here, that prevents the evaluation of the 
> babel call above:
>
>
>>  #+NAME: rekursio-pystyviivat
>>  #+BEGIN_SRC processing :exports code :noweb no
>
> I am not sure I find this new behavior to be an improvement.

The new behaviour actually makes sense to me: I need to override all the
parameters from the original Babel block. If this is really the case, I
am more than fine with it: I think it makes the system more logical and
provides full control.

Again, thanks!

Jarmo

Re: Babel CALL no longer produces HTML output

[Charles C. Berry]

On Sat, 23 Jul 2016, Nicolas Goaziou wrote:

> Hello,
>
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> IIUC, one result is that header args in the src block being called take
>> precedence over default header args. More below.
>
> [...]
>
>> I am not sure I find this new behavior to be an improvement.
>
> Having default header args to take precedence over local ones seems
> counter-intuitive. It makes it harder to override them, and harder to
> reason about the current active headers.
>
> 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.

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.

Chuck

Re: Babel CALL no longer produces HTML output

[Christian Moe]

Jarmo Hurri writes:

>> Try:
>>
>>     #+CALL: rekursio-pystyviivat[:noweb yes]() :results export html
>
> Greetings Christian,
>
> for some reason that did not improve the end result.

Sorry, I had that solution freshly in mind from a different problem
(involving #+INCLUDE, not #+CALL), and typed without thinking. I see
Charles Berry had the right answer.

Yours,
Christian

Re: Babel CALL no longer produces HTML output

[Nicolas Goaziou]

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

Re: Babel CALL no longer produces HTML output

[Thomas S. Dye]

Aloha Nicolas,

Nicolas Goaziou writes:

> 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.

Perhaps this should be added to the default value of
org-babel-default-lob-header-args for the sake of legacy code?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Babel CALL no longer produces HTML output

[Nicolas Goaziou]

Hello,

"Thomas S. Dye" <tsd@tsdye.com> writes:

> Nicolas Goaziou writes:
>
>> You may want to add (:eval . "yes") to
>> `org-babel-default-lob-header-args' if you disagree.
>
> Perhaps this should be added to the default value of
> org-babel-default-lob-header-args for the sake of legacy code?

I don't think so, for three reasons:

1. `org-babel-default-lob-header-args' didn't include this association previously;

2. unlike to :exports, there is no obvious default value for the :eval
   argument; the expected default value would be to unset :eval, which
   requires another mechanism;
   
3. I think it is dangerous to assume and Babel call can be evaled, even if
   the original source block cannot; after all, the user explicitly
   marked the original code block with ":eval no" for a reason.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: Babel CALL no longer produces HTML output

[Charles C. Berry]

On Mon, 25 Jul 2016, Nicolas Goaziou wrote:

> Hello,
>
> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> Nicolas Goaziou writes:
>>
>>> You may want to add (:eval . "yes") to
>>> `org-babel-default-lob-header-args' if you disagree.
>>
>> Perhaps this should be added to the default value of
>> org-babel-default-lob-header-args for the sake of legacy code?
>
> I don't think so, for three reasons:
>
> 1. `org-babel-default-lob-header-args' didn't include this association previously;
>
> 2. unlike to :exports, there is no obvious default value for the :eval
>   argument; the expected default value would be to unset :eval, which
>   requires another mechanism;
>
> 3. I think it is dangerous to assume and Babel call can be evaled, even if
>   the original source block cannot; after all, the user explicitly
>   marked the original code block with ":eval no" for a reason.
>

Fair enough.

I can think of reasons why a user would want to do this, but the current 
setup accomodates those pretty well.

Chuck

Re: Babel CALL no longer produces HTML output

[Thomas S. Dye]

Aloha,

Nicolas Goaziou writes:

> Hello,
>
> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> Nicolas Goaziou writes:
>>
>>> You may want to add (:eval . "yes") to
>>> `org-babel-default-lob-header-args' if you disagree.
>>
>> Perhaps this should be added to the default value of
>> org-babel-default-lob-header-args for the sake of legacy code?
>
> I don't think so, for three reasons:
>
> 1. `org-babel-default-lob-header-args' didn't include this association previously;
>
> 2. unlike to :exports, there is no obvious default value for the :eval
>    argument; the expected default value would be to unset :eval, which
>    requires another mechanism;
>    
> 3. I think it is dangerous to assume and Babel call can be evaled, even if
>    the original source block cannot; after all, the user explicitly
>    marked the original code block with ":eval no" for a reason.
>
> WDYT?

I agree with the logic behind the changes.  My suggestion is intended to
keep legacy code functioning as it did when it was written, that's all.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com