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 ALh7FycuWV8JKQAA0tVLHw (envelope-from ) for ; Wed, 09 Sep 2020 19:33:59 +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 mAZnEycuWV8EYQAAbx9fmQ (envelope-from ) for ; Wed, 09 Sep 2020 19:33:59 +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 E388C940917 for ; Wed, 9 Sep 2020 19:33:58 +0000 (UTC) Received: from localhost ([::1]:50310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kG5qv-0005IU-Q8 for larch@yhetil.org; Wed, 09 Sep 2020 15:33:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kG5qW-0005IM-G4 for emacs-orgmode@gnu.org; Wed, 09 Sep 2020 15:33:32 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:37967) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kG5qT-0006MQ-II; Wed, 09 Sep 2020 15:33:32 -0400 Received: by mail-wr1-x431.google.com with SMTP id g4so4193158wrs.5; Wed, 09 Sep 2020 12:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SN/EdyT6zx1SCDUCw20d+yeyR6Z3de9Yv2whL7k75x0=; b=VCEvUy/1K7EnQ7aXqBMjGSP3B3/7Lk1WSPX87qS6MB9bR6rU+OAfnTEGUsoRZXODyf QZRTSdxQCbI6483TyvN0xx+xF9ZTDJtkYsqd3dCbgHDccN+wgaX5+ASdzgYKMcUYVUsn EBAqwVSa0G4nnvfSmREhLVmRc6V9pOsLZvm2b88zpvpCwUINppmIcyXy4Qnn8jW1auIp 9obJSe9KkQTjknqFfuULNVgsSeZrb3QIxgKltgI4UkpVOUseOR11LX62YfGhGaUFTLWD 91JrWcrynW8urgTv23j6L+vr7AZSvumDuAOihQe55bK93yl8PCok2KGkBmKh7nF/ZHrA X+2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SN/EdyT6zx1SCDUCw20d+yeyR6Z3de9Yv2whL7k75x0=; b=bwlYifiOX74elV1Us8HmBOSwm8ih7gUM7NzrhaHTRtn4l+k5EuPwIHM4XsOKosvdLt 7RwUetx+wgfVBK8y3JIhmYJURVgBqJhftqOKyvvpBJaEOVkM+CuqwBwUxx9qINt5k+l8 s6qex+5oZfWO5Rsom6iH/efWgmfJd08yWMcte1bE9tVwMscSiMTkCmFRVqL8hclo92M+ F9Y8DtROIK35rxOSB6IKbov+QQi9nQBo8P3oAvXLsK0AjojiDQpJA5BRQ5w9Zj6dfJLb P8jGQZWqRHDxBXdYi0C7QXPzTT4UiyckBxgZaifqiWQJHnwCgF4NjSDMhylN/GVC4kG4 HMgw== X-Gm-Message-State: AOAM533xMRb16XAlAk/1tdoZrfuIdcx0kjfvSGjMaeQv/aZTcv2wKz11 2AuGllSDu9GmsNFzQPVYne606zJTOckWnyGzEJk= X-Google-Smtp-Source: ABdhPJyE3MKj1nMbpM+m70/xjyoGhFnm0bxeooGae7+vVIMs86FmsVT2Vt568bRYdOIIZO6tvFcH1ccjPRdMrtyBg54= X-Received: by 2002:adf:fc92:: with SMTP id g18mr5794305wrr.201.1599680007210; Wed, 09 Sep 2020 12:33:27 -0700 (PDT) MIME-Version: 1.0 References: <87ftflikkc.fsf@gmail.com> <871rjqprdu.fsf@gmail.com> <875z8wxis3.fsf@gmail.com> <87k0x8dy3s.fsf@gnu.org> <87y2lizs63.fsf@gmail.com> In-Reply-To: <87y2lizs63.fsf@gmail.com> From: Tom Gillespie Date: Wed, 9 Sep 2020 12:33:15 -0700 Message-ID: Subject: Re: babel default header args as functions To: Matt Huszagh Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x431.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bastien , "emacs-orgmode@gnu.org" 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=gmail.com header.s=20161025 header.b=VCEvUy/1; dmarc=pass (policy=none) header.from=gmail.com; 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.71 X-TUID: 4lzDA3VkzI4a Hi Matt, Looking good here. Thanks! Tom On Wed, Sep 9, 2020 at 12:06 PM Matt Huszagh wrote: > > Tom Gillespie writes: > > > [...] I have a number of use > > cases that I can imagine would benefit greatly from being able to > > define a :header-args: :header (lambda () "yay!") property as a > > closure (and actually I assumed that it would just work that way if I > > tried to do it, clearly not though). I can't tell for sure if the > > patch enables this behavior though or whether I would still get a > > Wrong type argument error. > > This should work. Do you have reason for believing it might not? With the patch applied this is working on my end. * test header :PROPERTIES: :header-args:bash: :tangle (lambda () "./from-header.sh") :END: #+begin_src bash :shebang "#!/usr/bin/env bash" echo yes #+end_src > > [...] Looking > > at the patch it seems that it preserves the behavior of performing the > > evaluation of the closures at the source block, but I'm not 100% sure. > > I'm not sure I completely understand what you mean here. However, the > closures are evaluated when point is at the source block, during the > source block evaluation, not when the default headers are declared. This > allows the closures to use context-dependent functionality (e.g. you can > call `org-element-at-point' inside the closure and retrieve whatever > information you want). Does this address your concern? Please clarify if > I've missed your point. Yep, you've got it. > > If the default header closures are being evaluated before checking > > whether they have been superseded by the headers on a block then that > > is incorrect and they should not be evaluated until it is clear that > > they are the value of the header for that block and have not been > > superseded. > > I've fixed my patch (attached) so that now closures are only evaluated > when they are used as part of the final set of headers. Great.