* Babel eval w/ C-c C-c but not (org-babel-execute-buffer) @ 2019-10-02 20:46 Ken Mankoff 2019-10-02 21:59 ` John Kitchin 0 siblings, 1 reply; 9+ messages in thread From: Ken Mankoff @ 2019-10-02 20:46 UTC (permalink / raw) To: emacs-orgmode@gnu.org 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 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 0 siblings, 1 reply; 9+ messages in thread From: John Kitchin @ 2019-10-02 21:59 UTC (permalink / raw) To: Ken Mankoff; +Cc: emacs-orgmode@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-02 21:59 ` John Kitchin @ 2019-10-10 6:04 ` Ken Mankoff 2019-10-10 16:22 ` Berry, Charles 2019-10-10 22:13 ` Tim Cross 0 siblings, 2 replies; 9+ messages in thread From: Ken Mankoff @ 2019-10-10 6:04 UTC (permalink / raw) To: emacs-orgmode@gnu.org; +Cc: John Kitchin 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 6:04 ` Ken Mankoff @ 2019-10-10 16:22 ` Berry, Charles 2019-10-10 16:43 ` Ken Mankoff 2019-10-10 22:13 ` Tim Cross 1 sibling, 1 reply; 9+ messages in thread From: Berry, Charles @ 2019-10-10 16:22 UTC (permalink / raw) To: Ken Mankoff; +Cc: emacs-orgmode@gnu.org, John Kitchin > 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 > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 16:22 ` Berry, Charles @ 2019-10-10 16:43 ` Ken Mankoff 2019-10-10 17:21 ` Berry, Charles 0 siblings, 1 reply; 9+ messages in thread From: Ken Mankoff @ 2019-10-10 16:43 UTC (permalink / raw) To: Berry, Charles; +Cc: emacs-orgmode@gnu.org, John Kitchin 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 16:43 ` Ken Mankoff @ 2019-10-10 17:21 ` Berry, Charles 2019-10-10 19:01 ` Berry, Charles 0 siblings, 1 reply; 9+ messages in thread From: Berry, Charles @ 2019-10-10 17:21 UTC (permalink / raw) To: Ken Mankoff; +Cc: emacs-orgmode@gnu.org, John Kitchin > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 17:21 ` Berry, Charles @ 2019-10-10 19:01 ` Berry, Charles 0 siblings, 0 replies; 9+ messages in thread From: Berry, Charles @ 2019-10-10 19:01 UTC (permalink / raw) To: Ken Mankoff; +Cc: emacs-orgmode@gnu.org, John Kitchin > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 6:04 ` Ken Mankoff 2019-10-10 16:22 ` Berry, Charles @ 2019-10-10 22:13 ` Tim Cross 2019-10-11 4:25 ` Ken Mankoff 1 sibling, 1 reply; 9+ messages in thread From: Tim Cross @ 2019-10-10 22:13 UTC (permalink / raw) To: emacs-orgmode; +Cc: John Kitchin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer) 2019-10-10 22:13 ` Tim Cross @ 2019-10-11 4:25 ` Ken Mankoff 0 siblings, 0 replies; 9+ messages in thread From: Ken Mankoff @ 2019-10-11 4:25 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-10-11 4:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2019-10-11 4:25 ` Ken Mankoff
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).