all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [Bug] [babel] calls in :noexport: subtrees evaluated
@ 2012-09-05  7:59 Andreas Leha
  2012-09-05 11:59 ` Sebastien Vauban
  0 siblings, 1 reply; 9+ messages in thread
From: Andreas Leha @ 2012-09-05  7:59 UTC (permalink / raw)
  To: emacs-orgmode

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)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05  7:59 [Bug] [babel] calls in :noexport: subtrees evaluated Andreas Leha
@ 2012-09-05 11:59 ` Sebastien Vauban
  2012-09-05 12:15   ` Andreas Leha
  2012-09-05 12:37   ` Nicolas Goaziou
  0 siblings, 2 replies; 9+ messages in thread
From: Sebastien Vauban @ 2012-09-05 11:59 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 11:59 ` Sebastien Vauban
@ 2012-09-05 12:15   ` Andreas Leha
  2012-09-05 12:37   ` Nicolas Goaziou
  1 sibling, 0 replies; 9+ messages in thread
From: Andreas Leha @ 2012-09-05 12:15 UTC (permalink / raw)
  To: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 11:59 ` Sebastien Vauban
  2012-09-05 12:15   ` Andreas Leha
@ 2012-09-05 12:37   ` Nicolas Goaziou
  2012-09-05 13:12     ` Andreas Leha
  2012-09-05 16:17     ` Sebastien Vauban
  1 sibling, 2 replies; 9+ messages in thread
From: Nicolas Goaziou @ 2012-09-05 12:37 UTC (permalink / raw)
  To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 12:37   ` Nicolas Goaziou
@ 2012-09-05 13:12     ` Andreas Leha
  2012-09-05 16:17     ` Sebastien Vauban
  1 sibling, 0 replies; 9+ messages in thread
From: Andreas Leha @ 2012-09-05 13:12 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 12:37   ` Nicolas Goaziou
  2012-09-05 13:12     ` Andreas Leha
@ 2012-09-05 16:17     ` Sebastien Vauban
  2012-09-05 16:40       ` Eric Schulte
  1 sibling, 1 reply; 9+ messages in thread
From: Sebastien Vauban @ 2012-09-05 16:17 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 16:17     ` Sebastien Vauban
@ 2012-09-05 16:40       ` Eric Schulte
  2012-09-05 18:53         ` Andreas Leha
  2012-09-05 19:39         ` Sebastien Vauban
  0 siblings, 2 replies; 9+ messages in thread
From: Eric Schulte @ 2012-09-05 16:40 UTC (permalink / raw)
  To: Sebastien Vauban; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 16:40       ` Eric Schulte
@ 2012-09-05 18:53         ` Andreas Leha
  2012-09-05 19:39         ` Sebastien Vauban
  1 sibling, 0 replies; 9+ messages in thread
From: Andreas Leha @ 2012-09-05 18:53 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Bug] [babel] calls in :noexport: subtrees evaluated
  2012-09-05 16:40       ` Eric Schulte
  2012-09-05 18:53         ` Andreas Leha
@ 2012-09-05 19:39         ` Sebastien Vauban
  1 sibling, 0 replies; 9+ messages in thread
From: Sebastien Vauban @ 2012-09-05 19:39 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-09-05 19:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-05  7:59 [Bug] [babel] calls in :noexport: subtrees evaluated Andreas Leha
2012-09-05 11:59 ` Sebastien Vauban
2012-09-05 12:15   ` Andreas Leha
2012-09-05 12:37   ` Nicolas Goaziou
2012-09-05 13:12     ` Andreas Leha
2012-09-05 16:17     ` Sebastien Vauban
2012-09-05 16:40       ` Eric Schulte
2012-09-05 18:53         ` Andreas Leha
2012-09-05 19:39         ` Sebastien Vauban

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.