emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Paul Sexton <psexton@xnet.co.nz>
Cc: emacs-orgmode@gnu.org
Subject: Re: [babel] By default, code blocks should not be evaluated during export
Date: Fri, 08 Apr 2011 07:50:04 -0600	[thread overview]
Message-ID: <87k4f4ygl3.fsf@gmail.com> (raw)
In-Reply-To: <loom.20110408T055427-629@post.gmane.org> (Paul Sexton's message of "Fri, 8 Apr 2011 04:23:26 +0000 (UTC)")

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/

  parent reply	other threads:[~2011-04-08 14:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2011-04-08 15:28   ` Nick Dokos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k4f4ygl3.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=psexton@xnet.co.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).