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 16:22:51 +0000


> On Oct 9, 2019, at 11:04 PM, Ken Mankoff <address@hidden> 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
> 
> 
> 





reply via email to

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