* Babel CALL no longer produces HTML output
@ 2016-07-23 12:14 Jarmo Hurri
2016-07-23 12:48 ` Christian Moe
2016-07-23 16:10 ` Charles C. Berry
0 siblings, 2 replies; 13+ messages in thread
From: Jarmo Hurri @ 2016-07-23 12:14 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 12:14 Babel CALL no longer produces HTML output Jarmo Hurri
@ 2016-07-23 12:48 ` Christian Moe
2016-07-23 13:03 ` Jarmo Hurri
2016-07-23 16:10 ` Charles C. Berry
1 sibling, 1 reply; 13+ messages in thread
From: Christian Moe @ 2016-07-23 12:48 UTC (permalink / raw)
To: Jarmo Hurri; +Cc: emacs-orgmode
> #+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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 12:48 ` Christian Moe
@ 2016-07-23 13:03 ` Jarmo Hurri
2016-07-24 17:00 ` Christian Moe
0 siblings, 1 reply; 13+ messages in thread
From: Jarmo Hurri @ 2016-07-23 13:03 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 12:14 Babel CALL no longer produces HTML output Jarmo Hurri
2016-07-23 12:48 ` Christian Moe
@ 2016-07-23 16:10 ` Charles C. Berry
2016-07-23 16:51 ` Nicolas Goaziou
2016-07-23 16:52 ` Jarmo Hurri
1 sibling, 2 replies; 13+ messages in thread
From: Charles C. Berry @ 2016-07-23 16:10 UTC (permalink / raw)
To: Jarmo Hurri; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 16:10 ` Charles C. Berry
@ 2016-07-23 16:51 ` Nicolas Goaziou
2016-07-23 22:16 ` Charles C. Berry
2016-07-23 16:52 ` Jarmo Hurri
1 sibling, 1 reply; 13+ messages in thread
From: Nicolas Goaziou @ 2016-07-23 16:51 UTC (permalink / raw)
To: Charles C. Berry; +Cc: Jarmo Hurri, emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 16:10 ` Charles C. Berry
2016-07-23 16:51 ` Nicolas Goaziou
@ 2016-07-23 16:52 ` Jarmo Hurri
1 sibling, 0 replies; 13+ messages in thread
From: Jarmo Hurri @ 2016-07-23 16:52 UTC (permalink / raw)
To: emacs-orgmode
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 16:51 ` Nicolas Goaziou
@ 2016-07-23 22:16 ` Charles C. Berry
2016-07-25 7:08 ` Nicolas Goaziou
0 siblings, 1 reply; 13+ messages in thread
From: Charles C. Berry @ 2016-07-23 22:16 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Jarmo Hurri, emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 13:03 ` Jarmo Hurri
@ 2016-07-24 17:00 ` Christian Moe
0 siblings, 0 replies; 13+ messages in thread
From: Christian Moe @ 2016-07-24 17:00 UTC (permalink / raw)
To: Jarmo Hurri; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-23 22:16 ` Charles C. Berry
@ 2016-07-25 7:08 ` Nicolas Goaziou
2016-07-25 7:48 ` Thomas S. Dye
0 siblings, 1 reply; 13+ messages in thread
From: Nicolas Goaziou @ 2016-07-25 7:08 UTC (permalink / raw)
To: Charles C. Berry; +Cc: Jarmo Hurri, emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-25 7:08 ` Nicolas Goaziou
@ 2016-07-25 7:48 ` Thomas S. Dye
2016-07-25 8:01 ` Nicolas Goaziou
0 siblings, 1 reply; 13+ messages in thread
From: Thomas S. Dye @ 2016-07-25 7:48 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Jarmo Hurri, emacs-orgmode, Charles C. Berry
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-25 7:48 ` Thomas S. Dye
@ 2016-07-25 8:01 ` Nicolas Goaziou
2016-07-25 15:55 ` Charles C. Berry
2016-07-25 17:27 ` Thomas S. Dye
0 siblings, 2 replies; 13+ messages in thread
From: Nicolas Goaziou @ 2016-07-25 8:01 UTC (permalink / raw)
To: Thomas S. Dye; +Cc: Jarmo Hurri, emacs-orgmode, Charles C. Berry
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-25 8:01 ` Nicolas Goaziou
@ 2016-07-25 15:55 ` Charles C. Berry
2016-07-25 17:27 ` Thomas S. Dye
1 sibling, 0 replies; 13+ messages in thread
From: Charles C. Berry @ 2016-07-25 15:55 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Jarmo Hurri, emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Babel CALL no longer produces HTML output
2016-07-25 8:01 ` Nicolas Goaziou
2016-07-25 15:55 ` Charles C. Berry
@ 2016-07-25 17:27 ` Thomas S. Dye
1 sibling, 0 replies; 13+ messages in thread
From: Thomas S. Dye @ 2016-07-25 17:27 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Jarmo Hurri, emacs-orgmode, Charles C. Berry
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-07-25 17:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-23 12:14 Babel CALL no longer produces HTML output Jarmo Hurri
2016-07-23 12:48 ` Christian Moe
2016-07-23 13:03 ` Jarmo Hurri
2016-07-24 17:00 ` Christian Moe
2016-07-23 16:10 ` Charles C. Berry
2016-07-23 16:51 ` Nicolas Goaziou
2016-07-23 22:16 ` Charles C. Berry
2016-07-25 7:08 ` Nicolas Goaziou
2016-07-25 7:48 ` Thomas S. Dye
2016-07-25 8:01 ` Nicolas Goaziou
2016-07-25 15:55 ` Charles C. Berry
2016-07-25 17:27 ` Thomas S. Dye
2016-07-23 16:52 ` Jarmo Hurri
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).