[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: per-file (or, really, per buffer) allowing/disallowing code block ex
From: |
Fedja Beader |
Subject: |
Re: per-file (or, really, per buffer) allowing/disallowing code block execution |
Date: |
Sat, 10 Sep 2022 00:19:08 +0000 |
> 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.
- per-file (or, really, per buffer) allowing/disallowing code block execution, Fedja Beader, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Steven Harris, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Fedja Beader, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, tomas, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/09
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution,
Fedja Beader <=
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/11
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/12
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Tim Cross, 2022/09/12
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/13
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Rudolf Adamkovič, 2022/09/19
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/19
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Rudolf Adamkovič, 2022/09/21
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Max Nikulin, 2022/09/22
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/22
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Fraga, Eric, 2022/09/19