From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MBe8Bp++F1/JdwAA0tVLHw (envelope-from ) for ; Wed, 22 Jul 2020 04:20:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id SJSAAp++F186YgAAbx9fmQ (envelope-from ) for ; Wed, 22 Jul 2020 04:20:47 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E1F3894051F for ; Wed, 22 Jul 2020 04:20:45 +0000 (UTC) Received: from localhost ([::1]:53520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jy6FH-0002lD-Cv for larch@yhetil.org; Wed, 22 Jul 2020 00:20:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jy6Ei-0002jt-NW for emacs-orgmode@gnu.org; Wed, 22 Jul 2020 00:20:09 -0400 Received: from pb-smtp20.pobox.com ([173.228.157.52]:52792) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jy6Ef-0007TS-BI for emacs-orgmode@gnu.org; Wed, 22 Jul 2020 00:20:08 -0400 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 7E889ED84B; Wed, 22 Jul 2020 00:20:01 -0400 (EDT) (envelope-from kyle@kyleam.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:date:message-id:mime-version:content-type; s=sasl; bh=Z/EADvyXo7XJkSv7eV/iSpbIj2o=; b=GHDo5ypZ8e7vWrLMbtoo 6rGjCAqTNWyw9EUEzG/ri+zvAe37yqFoT8wc3cE9/ZYFFd1uNrkG8SOe9dM2VeAK X9eJWG7l9jAhY3d1CJFESFkWUjSllusDyRiwGB8cCVOvbYeUn2j4W6XbuW3F3u1P EQqohdVXroX7+gfbt0USxJk= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 7803DED84A; Wed, 22 Jul 2020 00:20:01 -0400 (EDT) (envelope-from kyle@kyleam.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kyleam.com; h=from:to:cc:subject:in-reply-to:date:message-id:mime-version:content-type; s=mesmtp; bh=k2FeH5nBoD2QfxQMLXbKgt1uDAbKLFRwER621kFVeQM=; b=JxK3eTTtHxStCmROiV4Qx5OLxBG2Pk9HdWHptpsZBGlqVbDzyRF5rQDAf1gxdV6ksJz+eY8LhSx3iF5g1b0HfDCmV5yx9H33dBL5SVVqT5tuG+0iGYnbW2L+ochjRoLJMP0el7EzMDEx+KL4sFOcVOeJMlnPAPJKpuMA0S24I5I= Received: from localhost (unknown [45.33.91.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id BA99CED848; Wed, 22 Jul 2020 00:19:58 -0400 (EDT) (envelope-from kyle@kyleam.com) From: Kyle Meyer To: Tom Gillespie Subject: Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate In-Reply-To: Date: Wed, 22 Jul 2020 00:19:56 -0400 Message-ID: <87k0ywyydv.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 9ABBA358-CBD2-11EA-9758-F0EA2EB3C613-24757444!pb-smtp20.pobox.com Received-SPF: pass client-ip=173.228.157.52; envelope-from=kyle@kyleam.com; helo=pb-smtp20.pobox.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/22 00:20:01 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=pobox.com header.s=sasl header.b=GHDo5ypZ; dkim=pass header.d=kyleam.com header.s=mesmtp header.b=JxK3eTTt; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.21 X-TUID: m64H1tJQc75o Tom Gillespie writes: > On Sun, Jul 19, 2020 at 2:13 PM Kyle Meyer wrote: >> An option not mentioned above is to replace (nth 1 info) with the >> expanded body upstream of (when (org-babel-check-evaluate info) ...). >> Modifying the body in INFO is admittedly not pretty, but it's in line >> with what is done elsewhere (e.g., -expand-src-block, >> -exp-process-buffer, -load-in-session), as well as with how other INFO >> elements in -execute-src-block are handled. > > I considered this as well, and in fact I assumed that this is how it worked > before I looked to see the code was actually doing. I didn't know what the > consequences of making it work that way would be and tend to err on the > side of not kobbering data that some other function might expect to be in > an unmodified state. This would certainly be the most expedient solution. > > There would need to be a way to indicate that info should not expand noweb > references so that :noweb no-export can get the unexpanded form. Maybe > and optional argument =expand= that defaults to t? > (defun org-babel-get-src-block-info (&optional light datum expand) > ... ) Hmm, it looks like you're thinking of a different spot than I was referring to. I was talking about modifying (nth 1 info) in -execute-src-block, before the (when (org-babel-check-evaluate ...). Prior to commit 3b3fc520a, (nth 1 info) was modified in -execute-src-block but after org-babel-check-evaluate and org-babel-confirm-evaluate. That makes me think it'd probably be safe to do again, just a bit upstream in the same function. And I don't see a spot where modifying that element would be problematic. On the incoming end, INFO is passed to copy-tree if it is provided as an argument, and I don't think any of the functions that -execute-src-block feeds INFO to would be affected. But I of course could be overlooking something. On the other hand, if org-babel-get-src-block-info did the expansion, I'd be a bit more worried about downstream effects (though I haven't tried to trace things too closely). Also, -execute-src-block takes a PARAMS argument, and I think that needs to be merged with (nth 2 info) before considering whether to expand, so it seems like expanding in -get-src-block-info would be too soon. Regardless of whether modifying (nth 1 info) would work, I also think it'd be fine to instead go ahead with something along the lines of your initial patch. In that case, the main question is whether coderefs should be removed (as they currently are in your patch). If not, perhaps something like below (untested) would suffice. diff --git a/lisp/ob-core.el b/lisp/ob-core.el index e798595bd..230706b7f 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -238,7 +238,10 @@ (defun org-babel-check-confirm-evaluate (info) (if (functionp org-confirm-babel-evaluate) (funcall org-confirm-babel-evaluate ;; Language, code block body. - (nth 0 info) (nth 1 info)) + (nth 0 info) + (if (org-babel-noweb-p headers :eval) + (org-babel-expand-noweb-references info) + (nth 1 info))) org-confirm-babel-evaluate)))) (cond (noeval nil)