From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id SMZlE5bTnGKNmgAAbAwnHQ (envelope-from ) for ; Sun, 05 Jun 2022 18:02:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id SK5vEpbTnGLPGwEAG6o9tA (envelope-from ) for ; Sun, 05 Jun 2022 18:02:30 +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 D285E3AF6E for ; Sun, 5 Jun 2022 18:02:29 +0200 (CEST) Received: from localhost ([::1]:49684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxshw-0005d4-Ed for larch@yhetil.org; Sun, 05 Jun 2022 12:02:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxsfi-0005BS-Cs for emacs-orgmode@gnu.org; Sun, 05 Jun 2022 12:00:10 -0400 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:46657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxsff-0007QV-DU for emacs-orgmode@gnu.org; Sun, 05 Jun 2022 12:00:10 -0400 Received: by mail-pf1-x432.google.com with SMTP id j6so10891934pfe.13 for ; Sun, 05 Jun 2022 09:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=ktIxldovgIm4HUa3h2pQ6a0shO/B3OrfcO4tAclqGpQ=; b=i0MJ53xqcwhF18QfLPOxzLy/aOJP2DTCrog8yolaUZo5cJheY6C6s+JU0V6fcjJ2eD BpqgZ0jQnq3GnCLcbGwu/FC4BH2noj03RIFdC79ZjiFTxMWf8S7lH74upLRE0bGPpev9 QcXXNn7L1aMkAl0P+05buwTtqLz/1T5IZaTl9hTn2nosiT3QbLBy3M2nG/9BP4lYFsMH 5HRBwjXhCn830jJrXlb+ZvJ1reQ8AXlGnwFbGd6lK4UkmEpqm8DgVBFv9//g0cDFbK41 Ek/QQ2Xc4vHox7Kdlwu5W+5VXhI3yKMqzK/Y2dAic1a2Ti6dyebvFa3i3i6vcnRExtt9 PTeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:cc:subject:in-reply-to:references :date:message-id:mime-version; bh=ktIxldovgIm4HUa3h2pQ6a0shO/B3OrfcO4tAclqGpQ=; b=NydA9IHGCGVShvBgLbRcn/SwZxB9mMB+12qQYMJsylTm3l0tt1MG1ukwZ2DkwMucWF sqmdIB9uavVA5pJs60QyXFte97I9Wn7XKE36tCwciH+NLbXKCUKOsB1lMWN8TmC8/6Sw 0KtRhBDP5PpLlE8hbbk44C/WvxQ0YFUqLH6uLu9SDUpd4pSBis6uNi15DGO4R2obLm0O 0ijt4XB29yFjDkDRyM5hfPzEwe0OhioBvI4k3GwcDwrhmkLmDTCGJxQSuEtGZRUOoYOF Tgs9JnfzMjeBkp5ovw/rhmO/DslQp9l8AsuFqUDveH6JYjsE1UMP/q1zG7LBDNXwTFZq ZOww== X-Gm-Message-State: AOAM533FZxR7/ax7NA4Er5zdtBo7THcqJG9w/fNAB1G3QFcoPTCw+4b/ MYid1MZf6CaOfxVZH5xnl1nKEfx+d7w= X-Google-Smtp-Source: ABdhPJxtd99ThEt7ptgn2T6Z/WEDAYe8O+/t7U8JuG1orsjJXUktyLEr7TBMV9qsa0llsjlWRTth6g== X-Received: by 2002:a05:6a00:996:b0:50b:76b8:3bb1 with SMTP id u22-20020a056a00099600b0050b76b83bb1mr20262493pfg.9.1654444804738; Sun, 05 Jun 2022 09:00:04 -0700 (PDT) Received: from ryzen3950 (c-208-82-98-189.rev.sailinternet.net. [208.82.98.189]) by smtp.gmail.com with ESMTPSA id v9-20020aa78509000000b00518285976cdsm8934578pfn.9.2022.06.05.09.00.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 09:00:03 -0700 (PDT) From: Matt Huszagh To: Ihor Radchenko Cc: "emacs-orgmode@gnu.org" Cc: Subject: Re: [PATCH] Fix behavior of lambda default header arg vars In-Reply-To: <87ee035mnp.fsf@localhost> References: <87o87abjm5.fsf@gmail.com> <87ee035mnp.fsf@localhost> Date: Sun, 05 Jun 2022 09:00:01 -0700 Message-ID: <87ee03je2m.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=huszaghmatt@gmail.com; helo=mail-pf1-x432.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, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654444949; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ktIxldovgIm4HUa3h2pQ6a0shO/B3OrfcO4tAclqGpQ=; b=LgrnWtZxo5aJdYTy7n6GNUIu0v9+i+pBaw014ndFmts+rhlvd/e9VOOYTh22BmmsGlZ9CS JsBHIKPW+KEAkcGRgEdcnxbIaLwrPE5evXvHIw7WTFoAwKigfTv6bmzSIrFX0mC12X5yLk A8CRsqakWq846Z/huNTczAnk9bZow+htOh2wcptCLETDh7RLzoTH2+ajk/4/Hshpa/7UWb LyKRsUyxLWkFrvGjxHQY6DKxks0CEl036YQSGzjokUEhBpxZ9XXBPMOzfX72st/0kdu8pd HRVQPD8nn8bDOYNXoOv0gEGM4bOrye8nvAI+rcy8x4iGfEfMvvVdy1/xfjnLTQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654444949; a=rsa-sha256; cv=none; b=bQDXtrPGQsKVE2Hn5Y8gWlCV07bh44InJv7NwDcjCBOBVN/Vdy2YSBPAJstrju9icC7Fkc yvmUARhO2iw4HESviHEoQV9ihUriI0Rzo/JJGsLie1jctbj/RafEmw6MzlIB07dzNEiwpZ Ct7H7FTS1I5p7P2IxbWElWXOm0as8YC2PjTlIKO/VU8NMEZCoIVss/hzHrsoSmKN3EfPZE cCQB4mXu4vcnaBYnwqzug/xhQCP+H3qhjBhykKMyoiTrYoXCHlG50WzhCSsphjPiCa3nRR wxwfhIBSJ0CYQlDlvswxRUJo+zU6yu9+kesiblBIuspBZHi9JAtjRx8P0kGUNQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=i0MJ53xq; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Spam-Score: 8.39 X-Spam: Yes Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=i0MJ53xq; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Queue-Id: D285E3AF6E X-Spam-Score: 8.39 X-Migadu-Spam: Yes X-Migadu-Scanner: scn1.migadu.com X-TUID: Q84wF9bJgxGm > It would help if closure part and multi-variable part were split into > separate paragraphs. The closure part and muliple header argument part are already in separate paragraphs. The multiple header argument part, however, is incorporated into an introductory paragraph that very briefly describes the value syntax of org-babel-default-header-args and the types of alist values it supports. I did this because that introductory information is short and simple and so I felt it acceptable to incorporate the multiple header argument information. I don't feel this places a significant intellectual burden on the reader to follow, but I'm happy to insert a newline before "Some header arguments..." if you'd prefer. > Are you saying that _only some_ backends support multiple vars? Are > there backends that do not support? I think you're confused about "(e.g., :var for some language backends)": It's been a while since I created this patch and I don't remember exactly why I wrote it this way. I think it was based on the belief that not all language backends support variable passing in header arguments, though I honestly couldn't tell you at the moment whether this is true. In that vein, a semantically equivalent way to write this would be "(e.g., :var for language backends that support it)". Maybe all language backends support variable header arguments, in which case "(e.g., :var)" could be used here instead. In any case, the "some language backends" part of the phrase is not a qualification of "multiple", but of "variables". Nor is it correct to read it this way, as the statement is grammatically clear and correct. An equivalent statement would be: """ Some header arguments can be provided multiple times for a source block. An example of such a header argument is :var. """ > Or are you talking about multiple assignments to the same variable? No. The topic of multiple assignments to the same variable is not discussed here. > Also, the example is not helpful here. The example *is* helpful. It provides explicit direction for how to handle the non-obvious case of header arguments that can be passed multiple times, which isn't described much in the documentation. > The new docstring is confusing. The same paragraph is talking about > closures, then multiple header args, and gives an example without > closures. I don't think there's anything particularly confusing about this docstring. As already mentioned, that paragraph discusses acceptable alist values and multiple header args. Closures are mentioned only as one of the acceptable alist values, which puts them on the same level as strings. The more in-depth discussion of closures happens later, in its own paragraphs. Taking a step back, the structure of this docstring is: 1. A single sentence briefly describing org-babel-default-header-args. 2. A description of the syntax and acceptable values that can be assigned to org-babel-default-header-args. 3. A discussion of how to handle header arguments that can be provided multiple times. This explicit treatment is justified because this case is not intuitively obvious. 4. A discussion of closures (including why functions need to be provided as closures) and an example illustrating their usefulness. 2 and 3 are part of the same paragraph and 4 is several paragraphs (the precise number depends on whether you consider code blocks to be their own paragraph and how they break up surrounding text). This is a perfectly reasonable way to structure this information. There's no rule requiring that there be one topic per paragraph. Instead, paragraphs should be structured in a way that's clear, and in many cases (not all) that does result in a paragraph discussing one topic. But again, a reasonable alternative structure would be to separate 2 and 3 into their own paragraphs and I'm happy to do that. The multiple header argument discussion also doesn't need to be located where it is. It could alternatively go after the discussion of closures if you prefer that. Matt