From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WJdzGienrmPjfAEAbAwnHQ (envelope-from ) for ; Fri, 30 Dec 2022 09:53:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id AHSeGienrmMYSQEAauVa8A (envelope-from ) for ; Fri, 30 Dec 2022 09:53:59 +0100 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 453952E139 for ; Fri, 30 Dec 2022 09:53:59 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBB8S-0001OT-PO; Fri, 30 Dec 2022 03:53:04 -0500 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 1pBB8G-0001MS-0Y for emacs-orgmode@gnu.org; Fri, 30 Dec 2022 03:52:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBB8F-0006iX-53; Fri, 30 Dec 2022 03:52:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ogvnnAIYGj9IFg7N04TWA/kT0qrnI/0OoIzUrdFeHNQ=; b=p5MNKVEzezW5LIcLMTl1 Oif9pBMcIivYlW5H8T43cMKt/h8XejeL7BOAo7+ejIm1kPqZ0of1xbs/zztHfQmOLoU/oqFHDFEvG b1Zk+vl92Xv88r11X3slqphGSr59+j/X0IoCLxsrK38YPZ05zCvsRz7qyc/gkf+KZ+hYgI6nxzFnG W7X6OJmKwOg6HiuSXqeIh32RujlHSlIlUogQ9+ESDJCdiTEoU3xh7QDhkOGyoLPfS2GuKoo8gkQkv XVyTI7V4PNyNxfctL06O9qxLZmnIay19S41iV/+zXxoMTpg4zcU9247D4bxmbfcxS4DHBX4DrNixg /DW4/ozyRzvSrw==; Received: from [185.24.184.132] (helo=hal) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBB8E-000762-Ea; Fri, 30 Dec 2022 03:52:50 -0500 Received: by hal (Postfix, from userid 1000) id 7796B1E0401; Fri, 30 Dec 2022 09:52:48 +0100 (CET) From: Bastien To: Ihor Radchenko Cc: Tom Gillespie , Kyle Meyer , emacs-orgmode@gnu.org Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable In-Reply-To: <87h6xetbfn.fsf@localhost> (Ihor Radchenko's message of "Thu, 29 Dec 2022 16:35:40 +0000") Organization: GNU References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87k02fspxa.fsf@localhost> <87edsii4mo.fsf@gnu.org> <87h6xetbfn.fsf@localhost> Date: Fri, 30 Dec 2022 09:52:48 +0100 Message-ID: <878rips273.fsf@bzg.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672390439; a=rsa-sha256; cv=none; b=LWqB0MYqof0gZhS76FrLNWoCn3rB2tzBbbEno80UrFa9TN8JvOkLtN89AGjJMg9n3Y1WbN dkT5xSVpnwoGV2VCfsoMet27T6EyvaaQOmRsYe+I9x9Zlkqo284TytN5SMA2+1WVAInbIZ 4XrXIFuP7bG6L2rSYKK5O9Q7G2Y39eDlkoH2yVt2cRCmh0AHGQTQ454Ho5xRBchKyanmyD 3Y/Xzw5H2YedYI3hvtMklYj+2WONF9RPSDP6iMZWm1+bDhWecf/84jC9aXYkv0KzQWavIK 6RSOhLi1eWmEWPPiZXHO1wdGJWuG/Rgd0ePiPlyw7IfGm3mWwybs9lN6Fxc4Wg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=p5MNKVEz; 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"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672390439; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ogvnnAIYGj9IFg7N04TWA/kT0qrnI/0OoIzUrdFeHNQ=; b=sAg/yq2lYXgxVUlkd1ornMPnoooma1FdVbyGVW6BFrBIHvmyo7Z2d7Gx7d/+FsYDMPIqoO JaSpe9JL9KhNQGz2Nod4o3HDYi440kgs/D9x96AZQfz9dAdEfMyBL4ZCETSBt+8w/5LHej C1Kzyq+ybM7j/oN/fpKrv5gN/awFoCUHNk4H/y1VYMNYk1L+2q8urpmTCOTtl7QOImhV3P 6V6m+sVSbEhIKBKp5QzosXhBGlH5QT/P59i4//zJyx032ZNIsCE4u4fQlr/NzBz2cMDO9l XTVUVsGtHZmtyB8vIh/bcUCHihLhuT73vsmvj3uTAR6SUF+J9Z1KO82AEqH3ow== X-Spam-Score: -9.76 X-Migadu-Queue-Id: 453952E139 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=p5MNKVEz; 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"; dmarc=pass (policy=none) header.from=gnu.org X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -9.76 X-TUID: KlDo+cnuYlpH Thanks a lot for the detailed answer, very helpful. > What changed: The prompt previously displayed on code block evaluation > is now also displayed when expanding header arguments: I see nothing in etc/ORG-NEWS that describes this change: am I missing something? >> Whether it changed or not, what is the problem in 9.6? > > The problem is that Org now displays more queries. > >> How does the patch solves this problem? > > It allows disabling these new queries about lisp evaluation outside > code blocks without disabling code block eval confirmation completely. Is there a real use-case for this? It looks like the patch fixes the "too many queries" problem by providing a setup that is similar to what was the previous default (i.e. only asking about code block evaluation when org-confirm-babel-evaluate-cell is set to nil.) But are we sure that users need to confirm header args evaluation separately from code blocks evaluation? IOW I have difficulties understanding when these would be relevant: (setq org-confirm-babel-evaluate-cell nil) (setq org-confirm-babel-evaluate t) > I later suggested disabling the queries by default - mimicking the pre > 9.6 behaviour yet keeping the ability for concerned users enable the > extra confirmation. I think that's the best route: providing, optionnally, more, while not annoying users who don't want more. > Yes. Ideally, we need to improve the code evaluation query. It should > allow confirming evaluation in bulk and add some code blocks/files to > whitelist. Similar to `org--confirm-resource-safe'. I see, indeed. > A concern have been expressed that more queries may annoy users and > drive them towards setting `org-confirm-babel-evaluate' to nil globally. > Upon doing this, the future more flexible security queries may be not > used by such users. The future more flexible security queries will be made visibile enough so that users currently setting `org-confirm-babel-evaluate' to nil will *want* to have a look at it. >> Also, org-confirm-babel-evaluate-table-cell seems more explicit than >> org-confirm-babel-evaluate-cell. > > But it will not be accurate. The query is now displayed upon executing > `org-babel-read' -- cell refers to Elisp code "cell" here. Not to a > table cell. I find "cell" confusing here (as Max said earlier in the thread). It either refers to a table cell or, in Elisp jargon, a "cons cell" (or a "function cell"). What about modifying `org-confirm-babel-evaluate' to allow these values: - t : confirm header vars *and* code blocks - 'code : confirm code blocks - 'vars : confirm vars - nil : don't confirm and set the default value to 'code, while allowing concerned users to set it to `t' -- until we have a better system for evaluation query. WDYT? -- Bastien