emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Running babel blocks in :noexport: sections
@ 2012-10-27 19:03 John Hendy
  2012-10-27 20:14 ` Nicolas Goaziou
  2012-10-27 22:57 ` Eric Schulte
  0 siblings, 2 replies; 6+ messages in thread
From: John Hendy @ 2012-10-27 19:03 UTC (permalink / raw)
  To: emacs-orgmode

For papers and beamer presentations, I sometimes hide more "universal"
babel blocks inside a sort of setup headline. I thought I'd done this
before, but perhaps not... The idea would be like so:

* Data setup     :noexport:

#+begin_src R :session r

load libraries
read data files
do universal operations

#+end_src

* Slide

#+begin_src R :session r :exports results :results output graphics

subset(larger_data_set_from_above)
processing
plot something

#+end_src

I noticed today that my :noexport: setup sections (I had a couple)
were not updating. I re-defined a variable name further down in my
file and it was re-using the definition from an above setup section
(tagged with :noexport:). Just because I don't want it export doesn't
mean I don't want to have useful stuff in the headline...

Is this a bug/inappropriate setting, desirable based on how others use
:noexport: headlines, or would others see value in executing babel
blocks in :noexport: headlines?

If I /didn't/ want it executed, I'd use :execute no.


Thanks for any input,
John

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

* Re: Running babel blocks in :noexport: sections
  2012-10-27 19:03 Running babel blocks in :noexport: sections John Hendy
@ 2012-10-27 20:14 ` Nicolas Goaziou
  2012-10-27 22:57 ` Eric Schulte
  1 sibling, 0 replies; 6+ messages in thread
From: Nicolas Goaziou @ 2012-10-27 20:14 UTC (permalink / raw)
  To: John Hendy; +Cc: emacs-orgmode

Hello,

John Hendy <jw.hendy@gmail.com> writes:

> Is this a bug/inappropriate setting, desirable based on how others use
> :noexport: headlines, or would others see value in executing babel
> blocks in :noexport: headlines?
>
> If I /didn't/ want it executed, I'd use :execute no.

This is the behaviour of the new export engine. The current exporter
removes :noexport: sections before executing src blocks within (it
always did).


Regards,

-- 
Nicolas Goaziou

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

* Re: Running babel blocks in :noexport: sections
  2012-10-27 19:03 Running babel blocks in :noexport: sections John Hendy
  2012-10-27 20:14 ` Nicolas Goaziou
@ 2012-10-27 22:57 ` Eric Schulte
  2012-10-28 17:23   ` John Hendy
  1 sibling, 1 reply; 6+ messages in thread
From: Eric Schulte @ 2012-10-27 22:57 UTC (permalink / raw)
  To: John Hendy; +Cc: emacs-orgmode

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

John Hendy <jw.hendy@gmail.com> writes:

> For papers and beamer presentations, I sometimes hide more "universal"
> babel blocks inside a sort of setup headline. I thought I'd done this
> before, but perhaps not... The idea would be like so:
>
> * Data setup     :noexport:
>
> #+begin_src R :session r
>
> load libraries
> read data files
> do universal operations
>
> #+end_src
>
> * Slide
>
> #+begin_src R :session r :exports results :results output graphics
>
> subset(larger_data_set_from_above)
> processing
> plot something
>
> #+end_src
>
> I noticed today that my :noexport: setup sections (I had a couple)
> were not updating. I re-defined a variable name further down in my
> file and it was re-using the definition from an above setup section
> (tagged with :noexport:). Just because I don't want it export doesn't
> mean I don't want to have useful stuff in the headline...
>
> Is this a bug/inappropriate setting, desirable based on how others use
> :noexport: headlines, or would others see value in executing babel
> blocks in :noexport: headlines?
>
> If I /didn't/ want it executed, I'd use :execute no.
>
>
> Thanks for any input,
> John
>

Instead of tagging the headline as :noexport: you can add the COMMENT
flag to it.  This should result in your desired behavior.  See the
attached example.


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

#+Title: example

* COMMENT not exported but run
#+name: the-date
#+begin_src sh
  date
#+end_src

* exported and able to call into un-exported subtrees
The date today is,
#+call: the-date()

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


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

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

* Re: Running babel blocks in :noexport: sections
  2012-10-27 22:57 ` Eric Schulte
@ 2012-10-28 17:23   ` John Hendy
  2012-10-28 20:22     ` John Hendy
  0 siblings, 1 reply; 6+ messages in thread
From: John Hendy @ 2012-10-28 17:23 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

On Sat, Oct 27, 2012 at 5:57 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> For papers and beamer presentations, I sometimes hide more "universal"
>> babel blocks inside a sort of setup headline. I thought I'd done this
>> before, but perhaps not... The idea would be like so:
>>
>> * Data setup     :noexport:
>>
>> #+begin_src R :session r
>>
>> load libraries
>> read data files
>> do universal operations
>>
>> #+end_src
>>
>> * Slide
>>
>> #+begin_src R :session r :exports results :results output graphics
>>
>> subset(larger_data_set_from_above)
>> processing
>> plot something
>>
>> #+end_src
>>
>> I noticed today that my :noexport: setup sections (I had a couple)
>> were not updating. I re-defined a variable name further down in my
>> file and it was re-using the definition from an above setup section
>> (tagged with :noexport:). Just because I don't want it export doesn't
>> mean I don't want to have useful stuff in the headline...
>>
>> Is this a bug/inappropriate setting, desirable based on how others use
>> :noexport: headlines, or would others see value in executing babel
>> blocks in :noexport: headlines?
>>
>> If I /didn't/ want it executed, I'd use :execute no.
>>
>>
>> Thanks for any input,
>> John
>>
>
> Instead of tagging the headline as :noexport: you can add the COMMENT
> flag to it.  This should result in your desired behavior.  See the
> attached example.
>
>

Brilliant. That'll do just fine. Never knew about that!

John

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

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

* Re: Running babel blocks in :noexport: sections
  2012-10-28 17:23   ` John Hendy
@ 2012-10-28 20:22     ` John Hendy
  2012-10-28 21:14       ` Eric Schulte
  0 siblings, 1 reply; 6+ messages in thread
From: John Hendy @ 2012-10-28 20:22 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

Just kidding... just checked *Messages* buffer, and all the headlines
I converted to COMMENT headlines are *not* executing the enclosed
babel blocks.

Is there a setting for this you have and I don't?


John

On Sun, Oct 28, 2012 at 12:23 PM, John Hendy <jw.hendy@gmail.com> wrote:
> On Sat, Oct 27, 2012 at 5:57 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> For papers and beamer presentations, I sometimes hide more "universal"
>>> babel blocks inside a sort of setup headline. I thought I'd done this
>>> before, but perhaps not... The idea would be like so:
>>>
>>> * Data setup     :noexport:
>>>
>>> #+begin_src R :session r
>>>
>>> load libraries
>>> read data files
>>> do universal operations
>>>
>>> #+end_src
>>>
>>> * Slide
>>>
>>> #+begin_src R :session r :exports results :results output graphics
>>>
>>> subset(larger_data_set_from_above)
>>> processing
>>> plot something
>>>
>>> #+end_src
>>>
>>> I noticed today that my :noexport: setup sections (I had a couple)
>>> were not updating. I re-defined a variable name further down in my
>>> file and it was re-using the definition from an above setup section
>>> (tagged with :noexport:). Just because I don't want it export doesn't
>>> mean I don't want to have useful stuff in the headline...
>>>
>>> Is this a bug/inappropriate setting, desirable based on how others use
>>> :noexport: headlines, or would others see value in executing babel
>>> blocks in :noexport: headlines?
>>>
>>> If I /didn't/ want it executed, I'd use :execute no.
>>>
>>>
>>> Thanks for any input,
>>> John
>>>
>>
>> Instead of tagging the headline as :noexport: you can add the COMMENT
>> flag to it.  This should result in your desired behavior.  See the
>> attached example.
>>
>>
>
> Brilliant. That'll do just fine. Never knew about that!
>
> John
>
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte
>>

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

* Re: Running babel blocks in :noexport: sections
  2012-10-28 20:22     ` John Hendy
@ 2012-10-28 21:14       ` Eric Schulte
  0 siblings, 0 replies; 6+ messages in thread
From: Eric Schulte @ 2012-10-28 21:14 UTC (permalink / raw)
  To: John Hendy; +Cc: emacs-orgmode

John Hendy <jw.hendy@gmail.com> writes:

> Just kidding... just checked *Messages* buffer, and all the headlines
> I converted to COMMENT headlines are *not* executing the enclosed
> babel blocks.
>
> Is there a setting for this you have and I don't?
>

Not that I know of.

Are you using the new or the old exporter?  What behavior do you get
when running with emacs -Q?

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

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

end of thread, other threads:[~2012-10-28 21:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-27 19:03 Running babel blocks in :noexport: sections John Hendy
2012-10-27 20:14 ` Nicolas Goaziou
2012-10-27 22:57 ` Eric Schulte
2012-10-28 17:23   ` John Hendy
2012-10-28 20:22     ` John Hendy
2012-10-28 21:14       ` Eric Schulte

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