emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Babel eval w/ C-c C-c but not (org-babel-execute-buffer)


From: Berry, Charles
Subject: Re: [O] Babel eval w/ C-c C-c but not (org-babel-execute-buffer)
Date: Thu, 10 Oct 2019 17:21:49 +0000


> On Oct 10, 2019, at 9:43 AM, Ken Mankoff <address@hidden> wrote:
> 
> Hi Charles,
> 
> On 2019-10-10 at 18:22 +02, Berry, Charles <address@hidden> wrote...
>> If the language mode you use supports of evaluation of the src edit
>> buffer (e.g. ESS[R], Python), you can issue
>> 
>> C-c C-v v C-c C-b
>> 
>> for ESS[R] or
>> 
>> C-c C-v v C-c C-c
>> 
>> for Python (I think)
>> 
>> The commands will expand :var args and noweb declarations, then
>> execute the corresponding 'send-buffer' command regardless of :eval.
> 
> This could work in theory, but doesn't for bash on my system. And (I think) 
> with this method tables of output are not then injected back into the Org 
> buffer that can be exported as part of the document.


I think in R such tables are injected with :exports results/both.

But if you need bash, I guess not.

> 
>> Why not use something like this
>> 
>> :eval (ok2run)
>> 
>> where `ok2run' consults a property to decide whether to eval the block?
> 
> I need to think about this some more... Can you describe more how you picture 
> this working?

Try this:

#+begin_src org
  ,#+begin_src emacs-lisp 
    (defun ok2run (&optional eval-arg)
      "Use EVAL-ARG as the argument for `:eval'.
    If none is supplied consult
     a variable `buffer-eval-arg' if such exists
     a property called `eval-arg'
     or default to `yes'."
      (let ((eval-arg (or eval-arg
                          (bound-and-true-p buffer-eval-arg)
                          (org-entry-get (point) "eval-arg" t)
                          "yes")))
        eval-arg))
  ,#+end_src
#+end_src


#+begin_src org
  ,#+PROPERTY: header-args :eval (ok2run) :exports results

  ,* use default

  ,#+name: use-default
  ,#+begin_src emacs-lisp
  "unboundp"
  ,#+end_src

  ,* explicit no

  ,#+name: explicit-no
  ,#+begin_src emacs-lisp :eval (ok2run "no") 
  "explicit-no"
  ,#+end_src

  ,* never export in this subtree
    :PROPERTIES:
    :eval-arg: never-export
    :END:

  ,#+name: never-export
  ,#+begin_src emacs-lisp 
  "never-export"
  ,#+end_src
#+end_src


This will give fairly fine grained control over what and when to eval. 



> Off the top of my head, I am picturing a top-level property setting :eval 
> (ok2run) and then blocks I want to always run have :eval yes and blocks I 
> want to run interactively only have a new property, ":eval-on-c-c" set to 
> "t". The, (ok2run) checks for eval-on-c-c as a header arg and returns 't' if 
> it exists and 'nil' if it does not?
> 
> 
> While your suggestions do work for some cases, they feel like work-arounds 
> for a missing feature.


Perhaps, `org-confirm-babel-evaluate' is that feature. I think with a bit of 
effort it could do what I proposed above for `ok2run'.

> Isn't the feature I'm proposing a logical enhancement? Why would someone C-c 
> C-c (or C-u C-u C-c C-c) on a code block if they didn't want it to run? 
> Shouldn't an explicit request override a local header or top-level-document 
> flag that says "don't eval"?

Maybe it is logical. 

But I am a terrible typist and sometimes end up typing things or in places I 
did not intend. 

I have disabled a number of commands to prevent me from accidentally wrecking 
my work.  

So if I mark a block with `:eval no', I want to be sure errant keystrokes do 
not override that setting.

Chuck



reply via email to

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