From: Greg Minshall <minshall@umich.edu>
To: Fedja Beader <fedja@protonmail.ch>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution
Date: Tue, 06 Sep 2022 22:05:25 +0300 [thread overview]
Message-ID: <595135.1662491125@archlinux> (raw)
In-Reply-To: <l-mfSe5KD9g7LPdD7qHPtqtjBD45DK8OeOqO6ybMWqoXG-oEQAFjlW1V1N1NtJQBWM_A4CeGT_92rpSKF7Aq0KRzsNmMZfAJnAbyVWeCjoA=@protonmail.ch>
Fedja,
> What I would like to have, to safely and easily use org-mode
> as an interactive notebook, is to not have to overload this
> function and to be asked only once per buffer/file whether to:
> 1) Unconditionally allow executing all code blocks
> 2) Unconditionally disallow executing all code blocks
> 3) Ask for every block.
i think that is an interesting idea, and maybe a more pleasant user
interface than what we currently have.
probably, for me, it would allow me to drop a number of buffer-local
variable customizations, as i'm typically evaluating code in a given
buffer over and over again (and, so, would be happy to pay the price of
saying "yes" once per buffer (per emacs instance).
i'd be curious to hear what the downsides might be, especially anyone
who sees security-related downsides.
Ihor,
> 1) You can set org-confirm-babel-evaluate buffer-locally
> 2) Same or set :eval no header arg. (see
> https://orgmode.org/org.html#Evaluating-Code-Blocks)
> 3) You can set :eval query header arg.
for me the use case is 1) disabling all (or setting to "query") when,
e.g., you are exporting some file you received via e-mail and so trust
*none* of the code blocks; 2) enabling all for some file that you
yourself maintain, and so trust *all* the code blocks. at least
initially, this seems a nice direction.
cheers, Greg
next prev parent reply other threads:[~2022-09-06 19:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 23:50 per-file (or, really, per buffer) allowing/disallowing code block execution Fedja Beader
2022-09-06 13:33 ` Ihor Radchenko
2022-09-06 19:05 ` Greg Minshall [this message]
2022-09-07 0:17 ` Steven Harris
2022-09-07 8:49 ` Greg Minshall
2022-09-08 5:53 ` Ihor Radchenko
2022-09-08 12:34 ` Fedja Beader
2022-09-08 17:41 ` tomas
2022-09-09 5:50 ` Ihor Radchenko
2022-09-10 0:19 ` Fedja Beader
2022-09-11 9:10 ` Ihor Radchenko
2022-09-12 13:56 ` Greg Minshall
2022-09-12 20:38 ` Tim Cross
2022-09-13 4:47 ` Greg Minshall
2022-09-19 18:25 ` Rudolf Adamkovič
2022-09-19 19:28 ` Greg Minshall
2022-09-21 20:56 ` Rudolf Adamkovič
2022-09-22 14:17 ` Max Nikulin
2022-09-23 2:31 ` Ihor Radchenko
2022-09-19 9:23 ` Fraga, Eric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=595135.1662491125@archlinux \
--to=minshall@umich.edu \
--cc=emacs-orgmode@gnu.org \
--cc=fedja@protonmail.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).