From: "Berry, Charles" <ccberry@ucsd.edu>
To: Ken Mankoff <mankoff@gmail.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>,
John Kitchin <jkitchin@andrew.cmu.edu>
Subject: Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer)
Date: Thu, 10 Oct 2019 17:21:49 +0000 [thread overview]
Message-ID: <635C173F-5C04-4361-BC63-CA93DE277FA0@ucsd.edu> (raw)
In-Reply-To: <87r23k3612.fsf@gmail.com>
> 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
next prev parent reply other threads:[~2019-10-10 17:22 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 [this message]
2019-10-10 19:01 ` Berry, Charles
2019-10-10 22:13 ` Tim Cross
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=635C173F-5C04-4361-BC63-CA93DE277FA0@ucsd.edu \
--to=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
--cc=mankoff@gmail.com \
/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).