Re: per-file (or, really, per buffer) allowing/disallowing code block execution

[Fedja Beader <fedja@protonmail.ch>]

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


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