From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id aHusATTYG2Pd/QAAbAwnHQ (envelope-from ) for ; Sat, 10 Sep 2022 02:20:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id uA3QADTYG2MBugAAG6o9tA (envelope-from ) for ; Sat, 10 Sep 2022 02:20:04 +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 72999656B for ; Sat, 10 Sep 2022 02:20:03 +0200 (CEST) Received: from localhost ([::1]:44514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWoE6-0001AB-Ey for larch@yhetil.org; Fri, 09 Sep 2022 20:20:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWoDc-00019o-6Q for emacs-orgmode@gnu.org; Fri, 09 Sep 2022 20:19:32 -0400 Received: from mail-40135.protonmail.ch ([185.70.40.135]:11795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWoDZ-0006ko-Eg for emacs-orgmode@gnu.org; Fri, 09 Sep 2022 20:19:31 -0400 Date: Sat, 10 Sep 2022 00:19:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail3; t=1662769157; x=1663028357; bh=MVXWEfcM2C1QyNKnfn+uiZhFxDvZHlpuNihSJYvK2mQ=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=Cx8WH5M4wbwdiGXW87svAiMYdjC41xx+qqWc3lB8YkDLbluwvTwS690AgTKhDzyLz OxGsBFF5DL4Nld00LwllXv7pUOfpzNw4SuOyKxFPvxUBV+GXaxY0D4+EkbIamw1xTw yClNy6FpkZje461DIIFd8O/MJUSDClbM/wZVEzoW4W6oBBwrK1DKVgXu5Z8FN4493L dITxxDT3Qvvaacj7D0e/C/alabGV32hPIAo3HpJPJo8+Wk/C2hygDkCJfdUJTiEEcB Cl53xrYnygRK/RqIMl0mO0K7LqkRk+T8Owg60DJ1zDNM2ukK91PUN4UmCpwOPi+zA+ R+acB5Zui3IMA== To: Ihor Radchenko From: Fedja Beader Cc: "emacs-orgmode@gnu.org" Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution Message-ID: In-Reply-To: <877d2ddrkn.fsf@localhost> References: <595135.1662491125@archlinux> <87zgfao1hu.fsf@localhost> <877d2ddrkn.fsf@localhost> Feedback-ID: 216965:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.135; envelope-from=fedja@protonmail.ch; helo=mail-40135.protonmail.ch 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_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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: , Reply-To: Fedja Beader 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=1662769203; h=from:from:sender:sender:reply-to: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=MVXWEfcM2C1QyNKnfn+uiZhFxDvZHlpuNihSJYvK2mQ=; b=k1HacqM3wWm8uGVIf61C6w1yav3kiSV2JKCz1RzsIif2fT5quS6H0uBq2zkffW//Rs4Nip O2PlvVo8FbNnSqvnuq0FidDoSGktV50yIzDK2KJZuD+1tJb1mTZ3CqrwOuow0VEhh4CHe8 D3+NyNhFDymicgGWzIa5yicAlzly6HwGaZa24h38pTzDuIqqdPdZ5/YQAaEJ8V7o7ihaNV xlHo8HdtVhaoxyNRIooHgeSS6gxx1hZmz1jNvdofTp9OiUrFsMtGI4cUGEt3VrrcduuFVW eVWzsWxq5DnR/7InVvDikzWW6P+vh1ASGjPsBteOHhXPQO6E6+ejb9OxisLg8g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662769203; a=rsa-sha256; cv=none; b=KCpMgA+TTOp8JAdDqM3HBtFBzOoXIaq/NwpTaDZf00x5VlZmWFgjzAcpVkkYDzS+k8IDiE LLCVGqxD4h4ZhJglE1zZWXUZr4AHf8cFrFkdrYB51V9pkSAhGhDwrm9/OipSX/CE422bbR GkXWHbV3fFFgTowbSixHb74W2VRp5cEI9n5x4oX33RsHBvLhxbmARqvnQfhqXhFk7hdY+Y n+S/wfn9LiUnIAAgSXdW9MkoZw8shF4Y8GHmhdrwuts3VIf5kZlOUSS0DjXd1puYlgXSk0 Fy0Zjg+sy48vFeO9ns/EhLwxkfTxUoKbaFuRBtXZvMLw+FL3fdsBl4IkT76ifw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=Cx8WH5M4; dmarc=pass (policy=quarantine) header.from=protonmail.ch; 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: -2.29 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=Cx8WH5M4; dmarc=pass (policy=quarantine) header.from=protonmail.ch; 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: 72999656B X-Spam-Score: -2.29 X-Migadu-Scanner: scn1.migadu.com X-TUID: BxAlMH81+iEe > As Tomas pointed out, Emacs has a concept of safe and non-safe > file-local variables. org-confirm-babel-evaluate in particular is only > safe when it is set to t (query execution). If your downloaded file > attempts to set org-confirm-babel-evaluate to nil, Emacs will show a > warning and ask you whether you want to use this unsafe nil value. Can this mechanism be relied upon? I see in https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variabl= es.html that user may press ! to mark everything safe. This is less effort than the explicit "yes" required for executing a block on C-c C-c. > I am sorry if any of the answers to your suggestion sounded hostile. > The above does not mean that we reject your suggestion. Rather we try to > weigh on the available options in Org and Emacs itself and then try to > integrate the new feature into the existing concepts/functionalities. Not at all. If anything the reply of mine might have sounded such. Because your and Steven's initial replies focused on how to achieve this with different user-local changes, instead of making it automatic, it felt to me that my first email did not contain enough motivation behind such changes and that I had to clarify it again/further. > Note that Org mode already has a large number of customizations, which > is why we are trying to not introduce unnecessary customizations. Too > many options is not always a good thing. This makes me wonder how many of us have a custom init.el for the purpose discussed here. Surely I am not alone, and surely having such customisation maintained in org-mode itself would be better. > Yes-for-all/No-for-all may be implemented in multiple ways: > - During the current org-babel-execute-buffer call If the user determined that it is safe to execute all blocks once, then why would it not be safe to execute them again? > - From now until the buffer is closed This option is probably closest to what I want. > - Forever for this file path Also fine. But 1) then this would have to be stored somewhere outside of the file, else the user would still be asked if they want to load that unsafe local variable. Meaning that in that case babel could just ask the user directly. 2) As I learn to use Emacs, the number of restarts decreases, meaning that the session just lives forever. In that case the once per open nagging of babel is acceptable. > - Forever for this file path until the file contents is changed What would change the file if not the user, and if the user already approved the existing code, why would the user not approve their own additions to it? > - For some period of time Same response as above. > Moreover, the above may apply for all the src blocks in buffer or just a particular src block. Going through blocks one by one and whitelisting, then executing them seems like a reasonable course of action, so why not. However, it might be a bit difficult to implement? How would babel determine that a block is the same one, even if it changes? Position in file? > I doubt that all the options should be implemented in practice. We may > probably just allow yes-for-all when running org-babel-execute-buffer > but not individual C-c C-c on src blocks. I can see valid reasons to > allow (1) in current org-babel-execute-buffer-call; (2) until the buffer > is closed; (3) until the file contents is changed + limited by time. > However, 3 possible options in the dialogue may be disorienting: I would like the option to mark whole file as trusted without having to execute all blocks in it. > yes/no (each src block) > Yes/No (all src blocks in current org-babel-execute-buffer cal) all/none? always/never? > * (until the buffer is closed) allfornow? alluntilclose? > ! (until the buffer is closed and in the next 30 days, as long as the > buffer contents is not changed) I'd prefer having to type full words, so that it is obvious what the user meant.