[Bug] [babel] calls in :noexport: subtrees evaluated

[Bug] [babel] calls in :noexport: subtrees evaluated

[Andreas Leha]

Hi all,

it seems to me, that #+call lines in subtrees with the :noexport: tag
are evaluated.  Is this intended?

In my opinion, these #+calls should not be evaluated.

* Example
Export this subtree with org-export-dispatch.  You will have to wait for
more than 1+10 secs...

** To be exported
This should be exported.

#+call: Rsleep(secs=1)

** Not to be exported                                              :noexport:
This should *not* be exported.

#+call: Rsleep(secs=10)

* Code
#+name: Rsleep
#+begin_src R :var secs=3
  Sys.sleep(secs)
#+end_src

Regards,
Andreas

PS: I am on Org-mode version 7.9.1 (release_7.9.1-138-geeb5b9)

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Sebastien Vauban]

Hello Andreas,

Andreas Leha wrote:
> it seems to me, that #+call lines in subtrees with the :noexport: tag
> are evaluated.  Is this intended?

I think that, at least, it's not a bug. I don't /think/ it has never been
specified like that. But I still don't have a clear view of what is done, in
which order:

- processing macros
- inhibiting "noexport" subtrees
- evaluating code blocks (possibly with noweb calls)
- etc.

In fact, what you expect is that putting a tag ":noexport:" on a subtree would
propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
the one which inhibits code block evaluation during export (but allow
interactive evaluation).

> In my opinion, these #+calls should not be evaluated.

I really don't have any strong opinion about this, even if, without further
thinking, I'd favor the same behavior as the one you expected.

Best regards,
  Seb

[1] Notice the different spelling: with or without the dash.

-- 
Sebastien Vauban

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Andreas Leha]

Hi Sebastien,


"Sebastien Vauban"
<wxhgmqzgwmuf@spammotel.com> writes:

> Hello Andreas,
>
> Andreas Leha wrote:
>> it seems to me, that #+call lines in subtrees with the :noexport: tag
>> are evaluated.  Is this intended?
>
> I think that, at least, it's not a bug. I don't /think/ it has never been
> specified like that. But I still don't have a clear view of what is done, in
> which order:
>
> - processing macros
> - inhibiting "noexport" subtrees
> - evaluating code blocks (possibly with noweb calls)
> - etc.
>
> In fact, what you expect is that putting a tag ":noexport:" on a subtree would
> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
> the one which inhibits code block evaluation during export (but allow
> interactive evaluation).

Thanks for the pointer.  I am aware of that.  But this requires two
modifications, in order to get the desired behaviour: the :noexport: tag
and a 'eval no-export' property.

Just to
explain my use case.  I am doing a statistical analysis.  One "arm" in
that analysis is quite time consuming.  As it is one "arm" it is all
beneath one subtree.  But still split to several code blocks.
In that case it would be really handy to say :noexport: to the subtree
to
(1) not execute the lengthy code
(2) simultaneously omit the section in the exported pdf

Note, that I am also aware of the caching system.  I have been using it
a lot, but it sort of breaks the reproducible research paradigm and got
into my way too often.
>
>> In my opinion, these #+calls should not be evaluated.
>
> I really don't have any strong opinion about this, even if, without further
> thinking, I'd favor the same behavior as the one you expected.
>
> Best regards,
>   Seb
>
> [1] Notice the different spelling: with or without the dash.

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Nicolas Goaziou]

Hello,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

> Andreas Leha wrote:
>> it seems to me, that #+call lines in subtrees with the :noexport: tag
>> are evaluated.  Is this intended?
>
> I think that, at least, it's not a bug. I don't /think/ it has never been
> specified like that. But I still don't have a clear view of what is done, in
> which order:
>
> - processing macros
> - inhibiting "noexport" subtrees
> - evaluating code blocks (possibly with noweb calls)
> - etc.

As far as the new exporter goes (you may want to have a look at
`org-export-as' function), the order is:

 - Process macros.
 - Expand #+INCLUDE: keywords.
 - Evaluate code blocks.

Note that "noexport" sub-trees are not inhibited. The are just skipped
when the parse tree is processed.

To answer the OP, :noexport: tag is related to export, not to
src-blocks. There are already other ways to disable code evaluation on
subtrees. It may be useful, as in your case, to have their behaviour
linked, but again, sometimes not.

It's often better to keep separate things, well, separate.


Regards,

-- 
Nicolas Goaziou

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Andreas Leha]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> "Sebastien Vauban"
> <wxhgmqzgwmuf@spammotel.com> writes:
>
>> Andreas Leha wrote:
>>> it seems to me, that #+call lines in subtrees with the :noexport: tag
>>> are evaluated.  Is this intended?
>
> As far as the new exporter goes (you may want to have a look at
> `org-export-as' function), the order is:
>
>  - Process macros.
>  - Expand #+INCLUDE: keywords.
>  - Evaluate code blocks.
>
> Note that "noexport" sub-trees are not inhibited. The are just skipped
> when the parse tree is processed.
>
> To answer the OP, :noexport: tag is related to export, not to
> src-blocks. There are already other ways to disable code evaluation on
> subtrees. It may be useful, as in your case, to have their behaviour
> linked, but again, sometimes not.
>
> It's often better to keep separate things, well, separate.

My expectation still is the "linked" case, but I can live in the
unlinked org mode world.
Thanks for the clarification, anyway.

Regards,
Andreas

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Sebastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>> In fact, what you expect is that putting a tag ":noexport:" on a subtree would
>> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
>> the one which inhibits code block evaluation during export (but allow
>> interactive evaluation).
>>
>> I really don't have any strong opinion about this, even if, without further
>> thinking, I'd favor the same behavior as the one you expected.
>
> To answer the OP, :noexport: tag is related to export, not to
> src-blocks. There are already other ways to disable code evaluation on
> subtrees. It may be useful, as in your case, to have their behaviour
> linked, but again, sometimes not.
>
> It's often better to keep separate things, well, separate.

To see whether there is more weigh toward a solution or the other, I would
formulate the question this way:

    are there real use-cases where one would want to *not* export a subtree
    (by tagging it), though to *well* evaluate the code blocks it contains?

If the answer is yes, then, definitely, both things must really stay
separated.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Nicolas,
>
> Nicolas Goaziou wrote:
>> "Sebastien Vauban" writes:
>>> In fact, what you expect is that putting a tag ":noexport:" on a subtree would
>>> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
>>> the one which inhibits code block evaluation during export (but allow
>>> interactive evaluation).
>>>
>>> I really don't have any strong opinion about this, even if, without further
>>> thinking, I'd favor the same behavior as the one you expected.
>>
>> To answer the OP, :noexport: tag is related to export, not to
>> src-blocks. There are already other ways to disable code evaluation on
>> subtrees. It may be useful, as in your case, to have their behaviour
>> linked, but again, sometimes not.
>>
>> It's often better to keep separate things, well, separate.
>
> To see whether there is more weigh toward a solution or the other, I would
> formulate the question this way:
>
>     are there real use-cases where one would want to *not* export a subtree
>     (by tagging it), though to *well* evaluate the code blocks it contains?
>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: example.org --]
[-- Type: text/x-org, Size: 592 bytes --]

#+Title: Example

Results in heading [[#first]] are generated by un-exported code blocks in
heading [[#second]].

* first
  :PROPERTIES:
  :CUSTOM_ID: first
  :END:

Things my adviser cares about.

#+RESULTS: foo
: like some result: 3

* second                                                           :noexport:
  :PROPERTIES:
  :CUSTOM_ID: second
  :END:

Things my adviser does not care about, but which I need to keep, like
minutiae of generating the result.

#+Name: bar
- foo
- bar
- baz

#+Name: foo
#+begin_src sh :var bar=bar
  echo "like some result: $(echo $bar|wc -w)"
#+end_src

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Andreas Leha]

Eric Schulte <eric.schulte@gmx.com> writes:

> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>
>> Hi Nicolas,
>>
>> Nicolas Goaziou wrote:
>>> "Sebastien Vauban" writes:
>>>> In fact, what you expect is that putting a tag ":noexport:" on a subtree would
>>>> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
>>>> the one which inhibits code block evaluation during export (but allow
>>>> interactive evaluation).
>>>>
>>>> I really don't have any strong opinion about this, even if, without further
>>>> thinking, I'd favor the same behavior as the one you expected.
>>>
>>> To answer the OP, :noexport: tag is related to export, not to
>>> src-blocks. There are already other ways to disable code evaluation on
>>> subtrees. It may be useful, as in your case, to have their behaviour
>>> linked, but again, sometimes not.
>>>
>>> It's often better to keep separate things, well, separate.
>>
>> To see whether there is more weigh toward a solution or the other, I would
>> formulate the question this way:
>>
>>     are there real use-cases where one would want to *not* export a subtree
>>     (by tagging it), though to *well* evaluate the code blocks it contains?
>>
>
> #+Title: Example
>
> Results in heading [[#first]] are generated by un-exported code blocks in
> heading [[#second]].
>
> * first
>   :PROPERTIES:
>   :CUSTOM_ID: first
>   :END:
>
> Things my adviser cares about.
>
> #+RESULTS: foo
> : like some result: 3
>
> * second                                                           :noexport:
>   :PROPERTIES:
>   :CUSTOM_ID: second
>   :END:
>
> Things my adviser does not care about, but which I need to keep, like
> minutiae of generating the result.
>
> #+Name: bar
> - foo
> - bar
> - baz
>
> #+Name: foo
> #+begin_src sh :var bar=bar
>   echo "like some result: $(echo $bar|wc -w)"
> #+end_src

I see the use case in the example.  It would have never occurred to me
to write it like that, though.  If I need the results in [[#first]] I'd always
have an appropriate #+call line in [[#first]] as well...

- Andreas

Re: [Bug] [babel] calls in :noexport: subtrees evaluated

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Nicolas Goaziou wrote:
>>> "Sebastien Vauban" writes:
>>>> In fact, what you expect is that putting a tag ":noexport:" on a subtree would
>>>> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's
>>>> the one which inhibits code block evaluation during export (but allow
>>>> interactive evaluation).
>>>>
>>>> I really don't have any strong opinion about this, even if, without further
>>>> thinking, I'd favor the same behavior as the one you expected.
>>>
>>> To answer the OP, :noexport: tag is related to export, not to
>>> src-blocks. There are already other ways to disable code evaluation on
>>> subtrees. It may be useful, as in your case, to have their behaviour
>>> linked, but again, sometimes not.
>>>
>>> It's often better to keep separate things, well, separate.
>>
>> To see whether there is more weigh toward a solution or the other, I would
>> formulate the question this way:
>>
>>     are there real use-cases where one would want to *not* export a subtree
>>     (by tagging it), though to *well* evaluate the code blocks it contains?
>
> #+Title: Example
>
> Results in heading "first" are generated by un-exported code blocks in
> heading "second".
>
> * first
>
> Things my adviser cares about.
>
> #+RESULTS: foo
> : like some result: 3
>
> * second                                                           :noexport:
>
> Things my adviser does not care about, but which I need to keep, like
> minutiae of generating the result.
>
> #+Name: bar
> - foo
> - bar
> - baz
>
> #+Name: foo
> #+begin_src sh :var bar=bar
>   echo "like some result: $(echo $bar|wc -w)"
> #+end_src

Accepted! ;-)

Best regards,
Seb

PS- Woudn't it be good if we standardize the "noexport"/"no-export" thing?
Have both the same (tag and property value)?

-- 
Sebastien Vauban