* [babel] By default, code blocks should not be evaluated during export
@ 2011-04-08 4:23 Paul Sexton
2011-04-08 6:56 ` Rainer M Krug
2011-04-08 13:50 ` Eric Schulte
0 siblings, 2 replies; 4+ messages in thread
From: Paul Sexton @ 2011-04-08 4:23 UTC (permalink / raw)
To: emacs-orgmode
The default value of `org-export-babel-evaluate' is t.
Having just crashed my Emacs session 5 times in a row trying to get
a file containing a BEGIN_SRC emacs-lisp ... END_SRC *code example*
to export to HTML...
I strongly feel it should default to nil.
I also feel that "executable code block" and "quoted code example that I would
like to display/export with pretty syntax highlighting" are two very different
concepts, and should have different block names.
eg #+BEGIN_EXEC for the executable blocks?
or allow an argument to example blocks, eg "#+BEGIN_EXAMPLE python" ?
Paul
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [babel] By default, code blocks should not be evaluated during export
2011-04-08 4:23 [babel] By default, code blocks should not be evaluated during export Paul Sexton
@ 2011-04-08 6:56 ` Rainer M Krug
2011-04-08 13:50 ` Eric Schulte
1 sibling, 0 replies; 4+ messages in thread
From: Rainer M Krug @ 2011-04-08 6:56 UTC (permalink / raw)
To: Paul Sexton; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/11 06:23, Paul Sexton wrote:
> The default value of `org-export-babel-evaluate' is t.
>
> Having just crashed my Emacs session 5 times in a row trying to get
> a file containing a BEGIN_SRC emacs-lisp ... END_SRC *code example*
> to export to HTML...
>
> I strongly feel it should default to nil.
>
> I also feel that "executable code block" and "quoted code example that I would
> like to display/export with pretty syntax highlighting" are two very different
> concepts, and should have different block names.
If you put
#+BABEL: :exports code
at the beginning of your file, only the code will be executed an not
evaluated - you can then use
#+begin_src python :exports results
YOUR CODE
#+end_src
to export the results (see "Working with source code --- Header
arguments --- Specific header arguments --- :exports" in the org manual
or am I missing something here?
Rainer
>
> eg #+BEGIN_EXEC for the executable blocks?
> or allow an argument to example blocks, eg "#+BEGIN_EXAMPLE python" ?
>
> Paul
>
>
>
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2esbkACgkQoYgNqgF2ego1YACeJgPio9ZCoXIO7q/p0l1dxSjX
U5wAn2vtTTbZIiKE03KPQs1AKa5YlBLw
=VVLi
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [babel] By default, code blocks should not be evaluated during export
2011-04-08 4:23 [babel] By default, code blocks should not be evaluated during export Paul Sexton
2011-04-08 6:56 ` Rainer M Krug
@ 2011-04-08 13:50 ` Eric Schulte
2011-04-08 15:28 ` Nick Dokos
1 sibling, 1 reply; 4+ messages in thread
From: Eric Schulte @ 2011-04-08 13:50 UTC (permalink / raw)
To: Paul Sexton; +Cc: emacs-orgmode
Hi Paul,
Paul Sexton <psexton@xnet.co.nz> writes:
> The default value of `org-export-babel-evaluate' is t.
>
The `org-export-babel-evaluate' is more of an external safety measure
for people who don't want *any* code block evaluation ever and IMO could
probably be removed as there is already `org-confirm-babel-evaluate'
(which could be augmented to allow an option for silently disallowing
evaluation).
>
> Having just crashed my Emacs session 5 times in a row trying to get
> a file containing a BEGIN_SRC emacs-lisp ... END_SRC *code example*
> to export to HTML...
>
> I strongly feel it should default to nil.
>
I can understand your frustration, however while the above does not
default to nil, the default babel header argument do not evaluate code
on export. See C-h v `org-babel-default-header-args'
,----
| org-babel-default-header-args is a variable defined in `ob.el'.
| Its value is ((:session . "none")
| (:results . "replace")
| (:exports . "code")
| (:cache . "no")
| (:noweb . "no")
| (:hlines . "no")
| (:tangle . "no")
| (:padnewline . "yes"))
|
|
| Documentation:
| Default arguments to use when evaluating a source block.
|
| [back]
`----
By default on export the code of code blocks will be exported, unless
you have changed the defaults in some way. Also, unless you have
changed the value of `org-confirm-babel-evaluate' you should have been
prompted before any evaluation. In fact after a quick local test with
'emacs -Q' emacs-lisp code blocks do not evaluate on export, so you have
something in your configuration explicitly causing this behavior.
>
> I also feel that "executable code block" and "quoted code example that I would
> like to display/export with pretty syntax highlighting" are two very different
> concepts, and should have different block names.
>
> eg #+BEGIN_EXEC for the executable blocks?
> or allow an argument to example blocks, eg "#+BEGIN_EXAMPLE python" ?
>
I very strongly disagree with this suggestion. As I see it code blocks
hold code. The use of the code is secondary to the content of the
block, and a header argument is an appropriate place to hold such usage
information. Also, it is common to switch between exporting results and
exporting code, and it would be onerous to change the code-block name.
Finally, this would complicate all of the current code block handling
code, having two separate blocks for a single semantic entity.
Best Regards -- Eric
>
> Paul
>
>
>
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [babel] By default, code blocks should not be evaluated during export
2011-04-08 13:50 ` Eric Schulte
@ 2011-04-08 15:28 ` Nick Dokos
0 siblings, 0 replies; 4+ messages in thread
From: Nick Dokos @ 2011-04-08 15:28 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode, nicholas.dokos, Paul Sexton
Eric Schulte <schulte.eric@gmail.com> wrote:
> Paul Sexton <psexton@xnet.co.nz> writes:
>
> >
> > Having just crashed my Emacs session 5 times in a row trying to get
> > a file containing a BEGIN_SRC emacs-lisp ... END_SRC *code example*
> > to export to HTML...
> >
> > I strongly feel it should default to nil.
> >
>
> I can understand your frustration, however while the above does not
> default to nil, the default babel header argument do not evaluate code
> on export. See C-h v `org-babel-default-header-args'
> >
> > I also feel that "executable code block" and "quoted code example that I would
> > like to display/export with pretty syntax highlighting" are two very different
> > concepts, and should have different block names.
> >
> > eg #+BEGIN_EXEC for the executable blocks?
> > or allow an argument to example blocks, eg "#+BEGIN_EXAMPLE python" ?
> >
>
> I very strongly disagree with this suggestion. As I see it code blocks
> hold code. The use of the code is secondary to the content of the
> block, and a header argument is an appropriate place to hold such usage
> information. Also, it is common to switch between exporting results and
> exporting code, and it would be onerous to change the code-block name.
> Finally, this would complicate all of the current code block handling
> code, having two separate blocks for a single semantic entity.
>
FWIW, I agree with Eric (modulo any bugs that might exist of course) -
otherwise babel loses much of its appeal for literate programming.
There are a couple of questions that need to be answered however:
o why is the code block evaluated during export in Paul's case? That may
be a result of Paul's config or a bug in babel - in either case, that
should be easy to fix and Eric addressed that.
o why did Paul's emacs session crash? That might be an emacs bug that
will need to be addressed. Even if Paul's elisp code is completely
broken, *it should not crash emacs*. Paul, can you post the code?
Actually, the whole org file if that's possible, as well as emacs and
org version?
Thanks,
Nick
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-04-08 15:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-08 4:23 [babel] By default, code blocks should not be evaluated during export Paul Sexton
2011-04-08 6:56 ` Rainer M Krug
2011-04-08 13:50 ` Eric Schulte
2011-04-08 15:28 ` Nick Dokos
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).