emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
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: Sun, 11 Sep 2022 17:10:06 +0800	[thread overview]
Message-ID: <8735cyxonl.fsf@localhost> (raw)
In-Reply-To: <CMF3FCXyBgscotfCMFy5598OTDjGOklEyvUQPLPnAhmmck2mol1rFymeeGTBf1L4PBRS2H6yA_puREavAGZh5eSKDniYDjFq4Bya7g1_bYg=@protonmail.ch>

Fedja Beader <fedja@protonmail.ch> writes:

>> 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-Variables.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.

While I agree with you, most people appear to prefer a single char. In
fact, it is very popular to replace _all_ the yes/no prompts in Emacs
with y/n prompts.

If you have an interest to change single-char prompt for buffer-local
variables, feel free to file a bug report to Emacs. AFAIK, there is
currently no way to customize this prompt.

>> 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.

I personally rarely use org-babel-execute-buffer and thus changed
org-confirm-babel-evaluate to nil + added default export :eval no-export
header arg. Since I run src blocks using C-c C-c, I always see what I am
about to execute.

>> 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?

Consider a code in Org file that makes dangerous things. It may be
useful to keep a query about execution just to stop and think for a
moment if you really want to do it. Not for every block in buffer, but

>> - 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.

The second option is a bit more consistent with file-local variable
handling and, more importantly, with `org--confirm-resource-safe' - the
approach we use to download remote #+SETUPFILE.

>> - 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.

I was mostly thinking about a file being replaced by a new downloaded
version. This is probably an overkill though.

>> 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?

We can use the same approach with :cache header argument. However, I
feel that it is also an overkill and will rarely be needed.

>> 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.

If we use the approach similar to `org--confirm-resource-safe' and
`org-safe-remote-resources', the safe files will be accumulated into a
custom variable. That custom variable can be modified by user just as
any other custom variable.

>> 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.

I also prefer full words, though it will be slightly inconsistent with
file-local variables and remote resource query in Org.


1. We can modify `org-babel-confirm-evaluate' to allow 3 extra answers:
- All (or maybe Yes, consistent with common bash script query)
- None (or maybe No, consistent with common bash script query)
- Always

The new version can be modelled after `org--confirm-resource-safe'.

Never is futile because user executing org-babel-execute-buffer will not
expect the command to be ignored.

Always will not be shown if `org-confirm-babel-evaluate' is not set to
'prompt or 'safe.

2. We can add C-h help buffer detailing what the answers to (similar to
   query-replace prompt)
3. We add a new custom variable org-confirm-babel-evaluate-safe-paths
   that will hold files marked safe.
4. We add two allowed values to `org-confirm-babel-evaluate': 'prompt
   and 'safe, just like in `org-resource-download-policy'. The default
   will be changed to 'prompt
5. We document changes in the manual and in the NEWS.

Patches are welcome!

Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

  reply	other threads:[~2022-09-11  9:11 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
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 [this message]
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:

  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=8735cyxonl.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=fedja@protonmail.ch \


* 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


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).