Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, Martin Gürtler wrote:


Am Donnerstag, 29. Dezember 2016, 09:07:40 CET schrieb Charles C. Berry:

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:

Dear list,
I am exporting the following org mode file:


[deleted]



But how would I control the (not-)inclusion of the src code during
export in that case?


As I wrote:

#+begin_quote

You might also note the advice in the docstring:

"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

#+end_quote


If that was not clear, review

(info "(org) Exporting code blocks")

particularly the paragraph that starts "Turning off evaluation..."


Chuck

Re: [O] src blocks: code is /always/ exported

[Lars E. Pettersson]

On 12/29/16 19:45, Martin Gürtler wrote:

I do not really need src block evaluation during export. I only need to
evaluate (manually) when I changed the graphics src, what I am doing
anyway to check the changed image.

But how would I control the (not-)inclusion of the src code during
export in that case?


I am using the following:

(add-to-list 'org-babel-default-header-args '(:eval . "never-export"))
(add-to-list 'org-babel-default-inline-header-args '(:eval . 
"never-export"))


Lars
--
Lars E. Pettersson 
http://www.sm6rpz.se/

Re: [O] src blocks: code is /always/ exported

[Martin Gürtler]

Am Donnerstag, 29. Dezember 2016, 09:07:40 CET schrieb Charles C. Berry:
> On Thu, 29 Dec 2016, "Martin Gürtler" wrote:
> > Dear list,
> > I am exporting the following org mode file:
> > 8<
> > * doc
> > #+BEGIN_SRC shell :exports none
> > ls |wc
> > #+END_SRC
> > 
> > #+RESULTS:
> > : 20  20 199
> > 
> > 8< I'd expect org mode to honour the
> > :exports none header argument and create a document that contains
> > only the result.  However, the exported document contains both, code
> > and results.  This seems to be independent of the type of SRC and
> > independent of the export type (I tried dot and shell for odt, latex
> > and beamer exports).  How can I get rid of the src code in the
> > exported document?
> 
> What does C-h v org-export-use-babel RET say?
> 
> If the result is not `t' that is the problem, and somewhere in your setup
> you have set that variable (or its predecessor org-export-babel-evaluate)
> to nil or something other than `t'.

That was indeed the culprit. I had switched it off to speed up export. After
setting that to t again it works (of course). Drawbacks are, that I need to
confirm the evaluation in each export (I am a bit hesitant to generally
accepting src block evaluation), and evaluation takes time.

I do not really need src block evaluation during export. I only need to
evaluate (manually) when I changed the graphics src, what I am doing
anyway to check the changed image.

But how would I control the (not-)inclusion of the src code during
export in that case?

Thanks,

Martin




signature.asc
Description: This is a digitally signed message part.

Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:


Dear list,
I am exporting the following org mode file:
8<
* doc
#+BEGIN_SRC shell :exports none
ls |wc
#+END_SRC
#+RESULTS:
: 20  20 199
8<
I'd expect org mode to honour the :exports none header argument and
create a document that contains only the result.
However, the exported document contains  both, code and results.
This seems to be independent of the type of SRC and independent of the
export type (I tried dot and shell for odt, latex and beamer exports).
How can I get rid of the src code in the exported document?


What does C-h v org-export-use-babel RET say?

If the result is not `t' that is the problem, and somewhere in your setup 
you have set that variable (or its predecessor org-export-babel-evaluate) 
to nil or something other than `t'.


If this is the problem, set org-export-use-babel to `t'. You might 
also note the advice in the docstring:


"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

HTH,

Chuck