From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ken Mankoff <mankoff@gmail.com>
Subject: Re: Babel eval w/ C-c C-c but not (org-babel-execute-buffer)
Date: Thu, 10 Oct 2019 18:43:37 +0200
Message-ID: <87r23k3612.fsf@gmail.com>
References: <87o8yyj2oe.fsf@gmail.com>
 <CAJ51ETpzHOTsE9vN+tSuHr8yWphDDosCuH_TqXevKUSsEjwMuA@mail.gmail.com>
 <877e5d3zmu.fsf@gmail.com> <31702816-69D2-450B-88A0-D6F7375C014C@ucsd.edu>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:44720)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <mankoff@gmail.com>) id 1iIbXT-0001lZ-PT
 for emacs-orgmode@gnu.org; Thu, 10 Oct 2019 12:43:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mankoff@gmail.com>) id 1iIbXS-0000Vv-IY
 for emacs-orgmode@gnu.org; Thu, 10 Oct 2019 12:43:43 -0400
Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:42252)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <mankoff@gmail.com>) id 1iIbXS-0000V0-BZ
 for emacs-orgmode@gnu.org; Thu, 10 Oct 2019 12:43:42 -0400
Received: by mail-lj1-x229.google.com with SMTP id y23so6875238lje.9
 for <emacs-orgmode@gnu.org>; Thu, 10 Oct 2019 09:43:41 -0700 (PDT)
In-reply-to: <31702816-69D2-450B-88A0-D6F7375C014C@ucsd.edu>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
 <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: "Berry, Charles" <ccberry@ucsd.edu>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>, John Kitchin <jkitchin@andrew.cmu.edu>

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.