From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 YM74D646H2P2owAAbAwnHQ (envelope-from ) for ; Mon, 12 Sep 2022 15:57:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 4LC0D646H2PYIQEAauVa8A (envelope-from ) for ; Mon, 12 Sep 2022 15:57:02 +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 B736F12019 for ; Mon, 12 Sep 2022 15:57:01 +0200 (CEST) Received: from localhost ([::1]:39384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oXjvo-0007vz-Pw for larch@yhetil.org; Mon, 12 Sep 2022 09:57:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXjv8-0007vA-No for emacs-orgmode@gnu.org; Mon, 12 Sep 2022 09:56:18 -0400 Received: from relay-egress-host.us-east-2.a.mail.umich.edu ([13.59.128.245]:43974 helo=itchy-ceridwen.relay-egress.a.mail.umich.edu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oXjv6-0004Mc-1B for emacs-orgmode@gnu.org; Mon, 12 Sep 2022 09:56:18 -0400 Received: from earnest-cyclops.authn-relay.a.mail.umich.edu (ip-10-0-72-105.us-east-2.compute.internal [10.0.72.105]) by itchy-ceridwen.relay-egress.a.mail.umich.edu with ESMTPS id 631F3A79.156D1020.140B0F6C.401439; Mon, 12 Sep 2022 09:56:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2018-08-29; t=1662990968; bh=Cyl2706LW5UDJVpBAMEQ0H69LfJ2EjrjmPfYAIYjF7Q=; h=To:cc:From:Subject:In-reply-to:References:Date; b=fgHncD0mE5kRb8KkXGgxWXYb7IcT7mRpa9eJlbqVE/GLE5hxYlciiicFcjTdg3i1r I+DlkB4C7Qb2L6RUKQKYQ7egUOOZCR9yGf3HebUG/3hdXSO/Vy4yHdCqEJI8lX21tJ YmQeGF1wWWezpHWmUiknvfEesS8TLfbwfha5NexF2y3Pyb1/1aIBOtD236sk/y7gf5 va/MIn0Z+/sEfUDepOBf3QDOOpMOTCkTmh8Mb2uzSioZTY/4rzMBLVLw6CKVPYDRRg l8Jcj4PIkRW5S2UFvafoFQNIegIAyEm+7/U96AuOfTY24SeMyzcXS4khh1MECRG6lE mrZHdbrfAmOZw== Received: from localhost (Mismatch [85.103.37.149]) by earnest-cyclops.authn-relay.a.mail.umich.edu with ESMTPSA id 631F3A77.1835B5E6.5D51D1F4.354329; Mon, 12 Sep 2022 09:56:08 -0400 To: Ihor Radchenko cc: Fedja Beader , "emacs-orgmode@gnu.org" From: Greg Minshall Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution In-reply-to: <8735cyxonl.fsf@localhost> References: <595135.1662491125@archlinux> <87zgfao1hu.fsf@localhost> <877d2ddrkn.fsf@localhost> <8735cyxonl.fsf@localhost> Comments: In-reply-to Ihor Radchenko message dated "Sun, 11 Sep 2022 17:10:06 +0800." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1.91 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1966687.1662990962.1@archlinux> Date: Mon, 12 Sep 2022 16:56:02 +0300 Message-ID: <1966694.1662990962@archlinux> Received-SPF: pass client-ip=13.59.128.245; envelope-from=minshall@umich.edu; helo=itchy-ceridwen.relay-egress.a.mail.umich.edu X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, 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=1662991022; 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=Cyl2706LW5UDJVpBAMEQ0H69LfJ2EjrjmPfYAIYjF7Q=; b=XNo2Brvdadm7oYOkSCqS1KPqGg4+S8PLl25zM1s5QMTi9im09gpm+h4Y5ertnfvsGMfLiC gTEYUbvo8ZdDbq8yW8PSR0SqTaNzvhbGV9onTbtEv9lfHIo+Sh2RYkB9NF0MtVQhu6MXKi 5vSCiRR4SWJ/K2XsN3S8LemDEiuBquFsj+GJ10iQtUOq1yTfqFjD/4+9Hp/Ck6iLYSY9+Z 45x++0o7c41bAXsl2r4WdwfS2nQAYm0DzkJ5atN0M7EbQg4YvRMV5giMEca3msXf5FTxgL hVfyRiahrOcQ9xWhIkmc7QxGC+yMX2o5VSJrnuYyaUIXCl/gw7Df8LNGX3avlA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662991022; a=rsa-sha256; cv=none; b=eqnKzUYaVJoHCC8ZguWJU9dCipryYm5zIZT4q3nLAjHyPmzaIYdxNnC7l8l7or8AAtSz5r pkVeRSJUJCkCQ15BIS2aK3hMjRTtB+6KKo2ol2mvmxWU58635VnHkIby7Rhr788DIHKDkV VM8/pw3liy6W8bNFrUQV/tNSPqDpL+Gw847P7ABxK64XzSSnrDi5z+Pn/X3q+R0OhBue5K Y7UhQIhPXK3UrlW3L0n5wuQInKchQzul9DX4rJkoN+7P/oC79NNvMVAjQOCnezRg6A3vAJ XhttQ3ulL2rWFcCX3cu4iXxNoTOTWTjOJDlH7VrntKu1fhGLI+OrpYKcKmeDyg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=umich.edu header.s=relay-2018-08-29 header.b=fgHncD0m; dmarc=pass (policy=none) header.from=umich.edu; 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: -4.41 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=umich.edu header.s=relay-2018-08-29 header.b=fgHncD0m; dmarc=pass (policy=none) header.from=umich.edu; 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: B736F12019 X-Spam-Score: -4.41 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2CNuABhEDb/f Ihor, Fedja, et al., i think this is very good. my suggestion would be to *not* permanently mark a file as safe (i.e., i would vote against org-confirm-babel-evaluate-safe-paths); rather, let a local variable do that. i worry about keeping state in "side cars" (if one calls them that), as it may be harder for the user to "grep" to find why some expected behavior is occurring, etc. in the "default" setting, asking to evaluate a src block would ask: - "yes" [y] - "no" [n] - "always this buffer" [Y?] - "never this buffer" [N?] the last two would only survive this buffer; once the buffer is closed and re-opened, you're back to "default" (unless, of course, there's a local variable set). Ihor, you suggested other meanings for "yes +". while they all are useful, i like the simplicity of just the "always for this buffer". and, per-src block seems overkill, and too complicated, too much state for the user to remember (but, i'm old, so memory is *always* an issue! :). when the user responds "always this buffer", maybe a message that, if they want the same behavior for future buffers of this same file, add a local variable. anyway, that's my 2 cents. cheers, Greg ps -- i'm neutral w.r.t. single letter versus word-length, completing read, prompts [the above suggestions notwithstanding].