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
next prev 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
List information: https://www.orgmode.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).