[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] [babel] confusion about org-confirm-babel-evaluate

From: Erik Iverson
Subject: Re: [Orgmode] [babel] confusion about org-confirm-babel-evaluate
Date: Thu, 12 Aug 2010 10:07:06 -0500
User-agent: Thunderbird (X11/20090812)

Nick Dokos wrote:
Eric S Fraga <address@hidden> wrote:

Hello all,

Back from a short holiday and trying to catch up on work... and so I
may have missed something in the org mailing list (although I've

I have a large file which includes many babel code blocks (mostly
maxima) that I wish to have evaluated on export.  This works except
that I have to confirm each evaluation (which takes some time).  I
know that org-confirm-babel-evaluate exists so I have put the
following at the top of my org file:

# -*- org-confirm-babel-evaluate: nil; -*-

checking the value of this variable (C-h v org-babel-confirm-evaluate)
gives me:

| org-confirm-babel-evaluate is a variable defined in `ob.el'.
| Its value is nil
| Local in buffer deferred-questions.org; global value is t
| | This variable is a file local variable.
|   This variable is safe as a file local variable if its value
|   satisfies the predicate which is byte-compiled expression.
| | Documentation:
| Confirm before evaluation.
| Require confirmation before interactively evaluating code
| blocks in Org-mode buffers.  The default value of this variable
| is t, meaning confirmation is required for any code block
| evaluation.  This variable can be set to nil to inhibit any
| future confirmation requests.  This variable can also be set to a
| [...]

so the value is indeed nil.  However, exporting to PDF, say, still
requires me to confirm each evaluation.  Typing C-c C-c doesn't
require confirmation, however, so the variable does seem to have some

What am I missing here to avoid having to confirm on export?  The only
variable I have found that combines both export and babel is
org-export-babel-evaluate which is not what I want.

Seems to me that the variable is not effective at all at this point in time:
it still has to be connected up and wired in. Here's what I see:

Org-mode version 7.01trans (release_7.01h.112.g13a0)
GNU Emacs (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2010-05-17 on 

org-babel-execute-src-block calls org-babel-confirm-evaluate in the
following context:

        (let (...
         (evaluation-confirmed (org-babel-confirm-evaluate info))

but evaluation-confirmed is not used anywhere. In fact, there is a comment
on the line above:

         ;; note the `evaluation-confirmed' variable is currently not
         ;; used, but could be used later to avoid the need for
         ;; chaining confirmations
         (evaluation-confirmed (org-babel-confirm-evaluate info))

but that's the *only* place where org-babel-confirm-evaluate is called,
so I don't think the function (or the variable that Eric is trying to
set) has any effect at all. I haven't chased things through to the C-c C-c
stage that Eric mentions, so I'm not sure what causes that.

Am I missing something?

org-babel-confirm-evaluate is a function.
org-confirm-babel-evaluate is a variable.

evaluation-confirmed is the result of evaluating the
org-babel-confirm-evaluate function.  So even though the
/result/ of that function isn't used yet, the function is still
called.  That function uses the value of org-confirm-babel-evaluate
to decide to prompt the user or not. So, as of now,
setting org-confirm-babel-evaluate to t or nil definitely has an

reply via email to

[Prev in Thread] Current Thread [Next in Thread]