Babel eval w/ C-c C-c but not (org-babel-execute-buffer)

Babel eval w/ C-c C-c but not (org-babel-execute-buffer)

[Ken Mankoff]

Hello,

I'm interested in having code blocks that do not eval when I run (org-babel-execute-buffer) but do when the cursor is within them and I explicitly want to execute them by entering C-c C-c.

I cannot get this behavior playing around with the :eval header argument. Is the behavior I described possible?

Thanks,

  -k.

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

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

I guess this is not easily possible without some advice. When you run
org-babel-execute-buffer the cursor moves into each block, so you need to
save the point before you run it, and then test if point has moved when
org-babel-execute-src-block is called.

It might be easier to write your own version of org-babel-execute-buffer
for this. You could use org-babel-map-src-blocks as the base, and in each
block run a test that determines if it should be executed.

John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Wed, Oct 2, 2019 at 4:48 PM Ken Mankoff <mankoff@gmail.com> wrote:

> Hello,
>
> I'm interested in having code blocks that do not eval when I run
> (org-babel-execute-buffer) but do when the cursor is within them and I
> explicitly want to execute them by entering C-c C-c.
>
> I cannot get this behavior playing around with the :eval header argument.
> Is the behavior I described possible?
>
> Thanks,
>
>   -k.
>
>

[-- Attachment #2: Type: text/html, Size: 1739 bytes --]

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

[Ken Mankoff]

Hello,

I think that even when ":eval no" is set, eval should happen if the user explicitly requests it.

The use case is that I have code that takes an unreasonable amount of compute time to run it in Emacs (e.g. a full day of compute time). I think even with :async this type of code should be run outside of emacs, so I tangle it and run the python or bash scripts in a terminal.

Elsewhere in the project (Org file) I have babel blocks that I want to update throughout the file. I do this by cleaning all result blocks with =C-u C-c C-v k= or (org-babel-remove-result-one-or-many), then executing all blocks (without =:eval no=) using =C-c C-v C-b= or (org-babel-execute-buffer).

In order to not spend days of compute time when I eval (org-babel-execute-buffer), I set :eval no to the computationally heavy babel blocks. But during development it would be nice to run these... hence the conflict with the current Org behavior and my desire for a new feature.

The two-line change at the bottom implements the following behavior:

When the prefix arg is passed to org-babel-execute-src-block, the block is evaluated regardless of the :eval flag.

Note that this doubles up on the prefix arg behavior, which is already set according to the documentation:

> With prefix argument ARG, force re-execution even if an existing
> result cached in the buffer would otherwise have been returned.

Questions for the list:

Is this feature something that makes sense?

If yes, then do you also think that tangling should occur when explicitly requested (i.e. C-u C-c C-v C-t), even if :tangle no is set?

Suggestions for a better implementation?

Thanks,

  -k.


diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 572f97919..9f9add334 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -646,7 +646,7 @@ block."
     ;; Merge PARAMS with INFO before considering source block
     ;; evaluation since both could disagree.
     (cl-callf org-babel-merge-params (nth 2 info) params)
-    (when (org-babel-check-evaluate info)
+    (when (or arg (org-babel-check-evaluate info))
       (cl-callf org-babel-process-params (nth 2 info))
       (let* ((params (nth 2 info))
 	     (cache (let ((c (cdr (assq :cache params))))
@@ -663,7 +663,7 @@ block."
 	    (let ((result (org-babel-read-result)))
 	      (message (replace-regexp-in-string "%" "%%" (format "%S" result)))
 	      result)))
-	 ((org-babel-confirm-evaluate info)
+	  ((or arg (org-babel-confirm-evaluate info))
 	  (let* ((lang (nth 0 info))
 		 (result-params (cdr (assq :result-params params)))
 		 ;; Expand noweb references in BODY and remove any

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

[Berry, Charles]

> On Oct 9, 2019, at 11:04 PM, Ken Mankoff <mankoff@gmail.com> wrote:
> 
> Hello,
> 
> I think that even when ":eval no" is set, eval should happen if the user explicitly requests it.


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. 

> 
> The use case is that I have code that takes an unreasonable amount of compute time to run it in Emacs (e.g. a full day of compute time). I think even with :async this type of code should be run outside of emacs, so I tangle it and run the python or bash scripts in a terminal.
> 
> Elsewhere in the project (Org file) I have babel blocks that I want to update throughout the file. I do this by cleaning all result blocks with =C-u C-c C-v k= or (org-babel-remove-result-one-or-many), then executing all blocks (without =:eval no=) using =C-c C-v C-b= or (org-babel-execute-buffer).
> 
> In order to not spend days of compute time when I eval (org-babel-execute-buffer), I set :eval no to the computationally heavy babel blocks. But during development it would be nice to run these... hence the conflict with the current Org behavior and my desire for a new feature.
> 


Why not use something like this

:eval (ok2run)

where `ok2run' consults a property to decide whether to eval the block? 



> The two-line change at the bottom implements the following behavior:
> 
> When the prefix arg is passed to org-babel-execute-src-block, the block is evaluated regardless of the :eval flag.
> 
> Note that this doubles up on the prefix arg behavior, which is already set according to the documentation:
> 
>> With prefix argument ARG, force re-execution even if an existing
>> result cached in the buffer would otherwise have been returned.
> 
> Questions for the list:
> 
> Is this feature something that makes sense?
> 
> If yes, then do you also think that tangling should occur when explicitly requested (i.e. C-u C-c C-v C-t), even if :tangle no is set?
> 
> Suggestions for a better implementation?
> 
> Thanks,
> 
>  -k.
> 
> 
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index 572f97919..9f9add334 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -646,7 +646,7 @@ block."
>     ;; Merge PARAMS with INFO before considering source block
>     ;; evaluation since both could disagree.
>     (cl-callf org-babel-merge-params (nth 2 info) params)
> -    (when (org-babel-check-evaluate info)
> +    (when (or arg (org-babel-check-evaluate info))
>       (cl-callf org-babel-process-params (nth 2 info))
>       (let* ((params (nth 2 info))
> 	     (cache (let ((c (cdr (assq :cache params))))
> @@ -663,7 +663,7 @@ block."
> 	    (let ((result (org-babel-read-result)))
> 	      (message (replace-regexp-in-string "%" "%%" (format "%S" result)))
> 	      result)))
> -	 ((org-babel-confirm-evaluate info)
> +	  ((or arg (org-babel-confirm-evaluate info))
> 	  (let* ((lang (nth 0 info))
> 		 (result-params (cdr (assq :result-params params)))
> 		 ;; Expand noweb references in BODY and remove any
> 
> 
> 

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

[Ken Mankoff]

Hi Charles,

On 2019-10-10 at 18:22 +02, Berry, Charles <ccberry@ucsd.edu> 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.

> 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? 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. 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"?

  -k.

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

[Berry, Charles]

> On Oct 10, 2019, at 9:43 AM, Ken Mankoff <mankoff@gmail.com> wrote:
> 
> Hi Charles,
> 
> On 2019-10-10 at 18:22 +02, Berry, Charles <ccberry@ucsd.edu> 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

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

[Berry, Charles]

> On Oct 10, 2019, at 10:21 AM, Charles Berry <ccberry@ucsd.edu> wrote:
> 
>> 
>> 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.
> 

Of course!

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


 Please chalk this one up to a brain f*rt.

Chuck

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

[Tim Cross]

My concern with this suggestion is that I think it my result in
'surprising' or unexpected results for users. I use tangle a fair
bit, but evaluate source blocks far less. I use :tangle no to mean do
not tangle - no if, but or maybe - if the block has :tangle no, then I
don not expect the block to be tangled. I would expect the same with
:export no.

This does not mean I don't understand your use case and the need to have
some additional control over the evalutaion/export of code
blocks. Perhaps an additional recognised configuration value for :export
and :tangle, such as 'manual', which might mean something like 'onle
evaluate/tangle this block when requested with block level commands, not
buffer level.

In short, understand the use case, but don't think overloading 'no' is
the correct route to take.

Tim

Ken Mankoff <mankoff@gmail.com> writes:

> Hello,
>
> I think that even when ":eval no" is set, eval should happen if the user explicitly requests it.
>
> The use case is that I have code that takes an unreasonable amount of compute time to run it in Emacs (e.g. a full day of compute time). I think even with :async this type of code should be run outside of emacs, so I tangle it and run the python or bash scripts in a terminal.
>
> Elsewhere in the project (Org file) I have babel blocks that I want to update throughout the file. I do this by cleaning all result blocks with =C-u C-c C-v k= or (org-babel-remove-result-one-or-many), then executing all blocks (without =:eval no=) using =C-c C-v C-b= or (org-babel-execute-buffer).
>
> In order to not spend days of compute time when I eval (org-babel-execute-buffer), I set :eval no to the computationally heavy babel blocks. But during development it would be nice to run these... hence the conflict with the current Org behavior and my desire for a new feature.
>
> The two-line change at the bottom implements the following behavior:
>
> When the prefix arg is passed to org-babel-execute-src-block, the block is evaluated regardless of the :eval flag.
>
> Note that this doubles up on the prefix arg behavior, which is already set according to the documentation:
>
>> With prefix argument ARG, force re-execution even if an existing
>> result cached in the buffer would otherwise have been returned.
>
> Questions for the list:
>
> Is this feature something that makes sense?
>
> If yes, then do you also think that tangling should occur when explicitly requested (i.e. C-u C-c C-v C-t), even if :tangle no is set?
>
> Suggestions for a better implementation?
>
> Thanks,
>
>   -k.
>
>
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index 572f97919..9f9add334 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -646,7 +646,7 @@ block."
>      ;; Merge PARAMS with INFO before considering source block
>      ;; evaluation since both could disagree.
>      (cl-callf org-babel-merge-params (nth 2 info) params)
> -    (when (org-babel-check-evaluate info)
> +    (when (or arg (org-babel-check-evaluate info))
>        (cl-callf org-babel-process-params (nth 2 info))
>        (let* ((params (nth 2 info))
>  	     (cache (let ((c (cdr (assq :cache params))))
> @@ -663,7 +663,7 @@ block."
>  	    (let ((result (org-babel-read-result)))
>  	      (message (replace-regexp-in-string "%" "%%" (format "%S" result)))
>  	      result)))
> -	 ((org-babel-confirm-evaluate info)
> +	  ((or arg (org-babel-confirm-evaluate info))
>  	  (let* ((lang (nth 0 info))
>  		 (result-params (cdr (assq :result-params params)))
>  		 ;; Expand noweb references in BODY and remove any


-- 
Tim Cross

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

[Ken Mankoff]

On 2019-10-11 at 00:13 +02, Tim Cross <theophilusx@gmail.com> wrote...
> My concern with this suggestion is that I think it my result in
> 'surprising' or unexpected results for users.

I hope nobody would be surprised if they C-u C-u C-c C-c'd ! :) Just as they shouldn't be surprised if the :cache is ignored, if run with prefix-arg. But I do understand your concern and agree with it.

> Perhaps an additional recognised configuration value for :export and
> :tangle, such as 'manual', which might mean something like 'onl[y]
> evaluate/tangle this block when requested with block level commands,
> not buffer level.

Yes, I agree this is preferred. The only reason I implemented the first version using prefix-arg is because I could see how to do that easily. I started down the path you describe above and ran into my own lisp and org limitations.

I'm open to implementation suggestions. My plan is to modify (org-babel-check-confirm-evaluate) and use introspection and see if (org-ctrl-c-ctrl-c) is in the call stack, and if so, return t. Does this make sense? Is there some better way to determine how org-babel-check-confirm-evaluate was reached? Or some better place to add the feature? Also, I'd use ":eval only-manual" unless someone suggests another value ("only-on-cc"?)

Thanks,

  -k.