From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id yDKZJeWW3GRdTQAASxT56A (envelope-from ) for ; Wed, 16 Aug 2023 11:29:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YLhOJeWW3GRh/QAAauVa8A (envelope-from ) for ; Wed, 16 Aug 2023 11:29:09 +0200 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 00889530CB for ; Wed, 16 Aug 2023 11:29:09 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=nU8VGhVp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692178149; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=HnIVcBwctAhalezgVeoTu0jgxsgnJ+YbYIs1WVy8BDQ=; b=cDP21B5JmFJJ5ZuJQtYuD4xnJM06AXod7Ypxjld/28cAUuTc8w+zTpRzPsejscmzlabsyV 59OPyZH2MMzpcbcL2cs8fOt511DOYW83+wPPabK+CN2rY2f4MXQS4JoDQ7XPkJBqqm9GRC 9Vb6jHq93Z49RvZ3vhbBsiwJc8r5gLMYqJnq4z4TQyvr+lMpGlIaKPSm+Z4DNCh6XUYT1Y /iEpTb/+3Dh64QI2jRP6AVqxd+pik9C5T9Ea3Wvtb8VpHoUhdPJF5ptuu3Al9+APJv/D3+ yYhTqOBAF1MmPCd/dv+CTLTrm+WIVugqqY1Khgn/m+mPB+Aef8uhf5uty6RHPg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=nU8VGhVp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692178149; a=rsa-sha256; cv=none; b=oF17wxkS0WAbVcRu5MzFUrGnBOr8QFNcsLQ0p1p3K2noJBMH99MhIFGgR2zjxrjt93+3Nw sEDXoeoTAxrgaJvgZ8UMTsgyoTsxVhYLN1Rh57dEpC8SQs6IdKozL/W5BIkBTJkD6KGLYz ZuSvdRynKmSYzAweA7TZ3fKLuhUJucsEg/5rDxSGL7xGRVahYtem4QVX/n2jMXiedYIJuX XUShjSrjhJa277E4Mue1OLylllVmSC/pK/9HYcAlAftIqbajPu/V5H0yqzhyL4A8FAis0P pPxph7kwtwp06WDJ5/CgHyTi/dma6y2UsvQen+HV0Qi1TByOuTxcTNBnM12vtA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qWCpG-0000qL-Qi; Wed, 16 Aug 2023 05:28:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWCpE-0000pq-Dn for emacs-orgmode@gnu.org; Wed, 16 Aug 2023 05:28:24 -0400 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qWCpC-0000Ps-19 for emacs-orgmode@gnu.org; Wed, 16 Aug 2023 05:28:24 -0400 Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3a76d882080so5354818b6e.2 for ; Wed, 16 Aug 2023 02:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692178100; x=1692782900; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HnIVcBwctAhalezgVeoTu0jgxsgnJ+YbYIs1WVy8BDQ=; b=nU8VGhVpEtBNYwAuz4pGAiGXJW7w3+tDrqzq6QtygW0Y4nn6/tHxOGVu1H7HcPtmH6 WTcYbQKriiZJog52ybqOJhQ1UYFpLQIqv7sfK+BYS85uAYWq64gjJcZEwrDqegUc2NOE PCI5HaFcpn/Woq3cGQeuL2+Rp8XA/wBlLhneSgaQp2XRyZ86CJxKv2U2ZvGTQK57bXUk QT4vmgqZrvEu89wejuaZ6GMqUotd/Pvr2r/C/3Wa4N2LKLz3Ry0sCKB5OzaLvRFk4cdu l06oSzlH68du3IdIdodICs0RsVc/ftwQw5TNcL7EtZOgjZmRpoLl/wCUJW7adEMlt4xn kywA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692178100; x=1692782900; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HnIVcBwctAhalezgVeoTu0jgxsgnJ+YbYIs1WVy8BDQ=; b=gLsDJ+dt2d/ot+sSZU7WcSI8GVU2oyQtz2AcOmN6D6nsiYmlYf9lMziwCTyWbhFUjc H6tvzXgPRF9xUNJAK6rLhUE0ZdpLmU2hhWZ3qlIdimz/EdCS2T7vbMtFm6Vct4cD65SQ +4tEkZg8ogqn5rBkRrs1nI7BihKy+staCdhdgLBk5dd0o0tqDxPtRTDhGhBXC1GepRiM v8CjubuCVTMfhOzz6UjN7HFZ1wdy/WH7WDpRbQDhOnG1gB0KfTGRb99e2b/QPpnTntCN 7kxE+fB91V2mFy8oRu2+Q+fQdJ3LDSejrB1JI02QYsBFEer3EFnkGCqZlkPvrn0PvFeB J88w== X-Gm-Message-State: AOJu0YzlPI0YhE4yX8nw3UYNr+bjJzuDmcIFQGr4rtr23ouS44XwCu1O /k+OM0IIDw8F7xO4lXHRo+zgs+VAxYia0RGhkDk= X-Google-Smtp-Source: AGHT+IHXcNL2Lpg3zKwM2vv2uPLAk5JnVfL+ss62crwQIjs4u5x1uEwlzKcmlrcWmhfgEhgNV8OnZ4NTJ4UL6TiZjEs= X-Received: by 2002:a05:6358:2486:b0:13a:2fed:337c with SMTP id m6-20020a056358248600b0013a2fed337cmr1576653rwc.24.1692178100470; Wed, 16 Aug 2023 02:28:20 -0700 (PDT) MIME-Version: 1.0 References: <877cpvpd4i.fsf@localhost> In-Reply-To: <877cpvpd4i.fsf@localhost> From: Tom Gillespie Date: Wed, 16 Aug 2023 02:28:08 -0700 Message-ID: Subject: Re: [PATCH] ob-tangle.el: restore :tangle closure nil behavior To: Ihor Radchenko Cc: emacs-orgmode Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::235; envelope-from=tgbugs@gmail.com; helo=mail-oi1-x235.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: -7.49 X-Migadu-Queue-Id: 00889530CB X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -7.49 X-TUID: PT+EuNLjYV4k On Wed, Aug 16, 2023 at 2:09=E2=80=AFAM Ihor Radchenko wrote: > > Tom Gillespie writes: > > > Subject: [PATCH] ob-tangle.el: restore :tangle closure evaluation befor= e eval > > info > > This patch fixes a bug where header arguments like :tangle (or "no") > > were treated as if they were tangling to a file named "(or \"no\")". > > As a result, org-bable would call org-babel-get-src-block-info with > > 'no-eval set to nil, causing parameters to be evaluated despite the > > fact that when :tangle no or equivalent is set, the other parameters > > should never be evaluated. > > What do you mean by "restore"? Were it evaluated in the past? > May you please provide a reproducer? Hrm. I think I may have mixed two commit lines. It is the case that :tangle closures used to work, but you are right, the historical behavior when tangling closures meant that all parameters were evaluated (tested with the block below in 27 and 28). #+begin_src elisp :var value=3D(error "oops") :tangle (or "no") value #+end_src My use case is that I have blocks that I want to tangle that set :var from e.g. the library of babel, which isn't always loaded, but which also is not required if :tangle is no. > > -(defun org-babel-tangle--unbracketed-link (params) > > +(defun org-babel-tangle--unbracketed-link (params &optional info-was-e= valed) > > This is not acceptable. Taking care about evaluating INFO should be done > in a single place instead of adding checks across the babel code. If we > go the proposed way, I expect a number of bugs appearing when somebody > forgets to change the eval check in some place. I don't like the solution either. I see two potential alternatives. 1. change the structure of the info list to indicate whether it has already been evaluated 2. always call org-babel-read on (cdr (assq :tangle params)) even if it may already have been evaluated which can lead to some unexpected and potentially nasty results. I don't think we can consolidate evaluating parameters into one place in the general case because there are order dependencies where a setting in one param header should mask others (as is the case here). In principle we could consolidate them, but I think that would add significant complexity because we would have to push all the logic for handling whether a given ordering restriction applies inside that location. e.g. if I have a block set :eval (if ev "yes" "no") it would be bad form to evaluate the parameters before determining whether the :eval closure evaluates to "yes" or "no". Should that go inside org-process-params, or should it be handled locally by e.g. org-babel-tangle and org-babel-execute-src-block separately? Thoughts?