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

[Tim Cross <theophilusx@gmail.com>]

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