all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Cc: John Kitchin <jkitchin@andrew.cmu.edu>
Subject: Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer)
Date: Fri, 11 Oct 2019 09:13:08 +1100	[thread overview]
Message-ID: <87eezk45cb.fsf@gmail.com> (raw)
In-Reply-To: <877e5d3zmu.fsf@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

  parent reply	other threads:[~2019-10-10 22:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02 20:46 Babel eval w/ C-c C-c but not (org-babel-execute-buffer) Ken Mankoff
2019-10-02 21:59 ` John Kitchin
2019-10-10  6:04   ` Ken Mankoff
2019-10-10 16:22     ` Berry, Charles
2019-10-10 16:43       ` Ken Mankoff
2019-10-10 17:21         ` Berry, Charles
2019-10-10 19:01           ` Berry, Charles
2019-10-10 22:13     ` Tim Cross [this message]
2019-10-11  4:25       ` Ken Mankoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eezk45cb.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jkitchin@andrew.cmu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.