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

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

[Fedja Beader]

Hello,

Pressing C-c C-c in a code block asks the user whether to
execute that code block or not. This soon becomes annoying.
To remedy this, org-mode provides us the variable
org-confirm-babel-evaluate. But this is not very user friendly.

Additionally, as per documentation, this variable only controls
whether org-mode (babel? Forgive me, I am sort of a new user of
Emacs) will execute the code block without asking, or ask.

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.

Particularly the second case is the one that cannot be
supported by simply defining org-confirm-babel-evaluate.

This is what I cooked up as a solution, with help and advice
from Ian Eure:


#+BEGIN_SRC elisp
(defvar-local org-babel-code-execute-mode nil)

(defun org-babel-check-confirm-evaluate-wrapper (orig-fun &rest args)
  (pcase org-babel-code-execute-mode
    ("always" t)
    ("never" nil)
    ("query" (apply orig-fun args))
    (- (progn
         (setq
           org-babel-code-execute-mode
           (completing-read ; can also return ""
             "Allow execution of code blocks in this buffer (always, never, query)?"
             '(always never query)
             nil ; predicate
             t ; require match to one of the three options
           )
         )
         (apply orig-fun args)
       )
    )
  )
)

(advice-add 'org-babel-check-confirm-evaluate :around #'org-babel-check-confirm-evaluate-wrapper)
#+END_SRC

I would like this functionality to become part of org-mode
in the future.

Sincerely,
Fedja

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

[Ihor Radchenko]

Fedja Beader <fedja@protonmail.ch> writes:

> Pressing C-c C-c in a code block asks the user whether to
> execute that code block or not. This soon becomes annoying.
> To remedy this, org-mode provides us the variable
> org-confirm-babel-evaluate. But this is not very user friendly.
>
> Additionally, as per documentation, this variable only controls
> whether org-mode (babel? Forgive me, I am sort of a new user of
> Emacs) will execute the code block without asking, or ask.
>
> 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.
>
> Particularly the second case is the one that cannot be
> supported by simply defining org-confirm-babel-evaluate.

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.


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

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

[Greg Minshall]

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

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

[Steven Harris]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

There is a neat solution to this problem using

* Local Variables :noexport:

see the discussion at stackoverflow
<https://stackoverflow.com/questions/20033467/setting-a-local-file-variable-in-emacs-org-mode>

Cheers,

Steven


On Wed, 7 Sept 2022 at 05:07, Greg Minshall <minshall@umich.edu> wrote:

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

[-- Attachment #2: Type: text/html, Size: 4307 bytes --]

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

[Greg Minshall]

Steven,

> There is a neat solution to this problem using
> 
> * Local Variables :noexport:
> 
> see the discussion at stackoverflow
> <https://stackoverflow.com/questions/20033467/setting-a-local-file-variable-in-emacs-org-mode>

thanks.  yes, if one has to do local variables, that is a very nice way
of doing it; i appreciate seeing that.

cheers, Greg

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

[Ihor Radchenko]

Greg Minshall <minshall@umich.edu> writes:

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

Then, what about the following:

1. Set org-confirm-babel-evaluate globally to t
2. In the files you maintain, you can always put
   file-local/directory-local value of org-confirm-babel-evaluate to
   nil.
3. We can modify org-babel-confirm-evaluate _function_ to accept four
   possible answers: yes, no, yes for all in buffer, no for all in
   buffer. The extra 2 options will set buffer-local value of
   org-confirm-babel-evaluate in the current Emacs session.

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

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

[Fedja Beader]

Hello Richard, Ihor and Steven,

I'm aware that file-local variables exist, but it seems that
all documentation for them put them *into the file*, which is not secure for files downloaded from the internet. What is to stop a malicious file from setting an "yes, execute me automatically" variable?

Anyway, the point of my email was to suggest a change to org-mode such that it provides a pleasant out-of-the-box user experience for people like me. I want to use org-mode as a python/octave/R/whatever interactive notebook without having to spend several days learning elisp and the internal workings of Emacs. I have spent these days, days that could be better (sorry!) used working on actual projects of mine. But I spent this time and the time to articulate what I want and to write these emails in the hope that I will be the last person having to do so. I would also like to suggest org-mode to other people instead of Jupyter notebook without having to add "oh, btw, you might want to add these three pages of alien code to your init.el to make it usable".

To go a bit further off-thread, this change might seem unnecessary. However, the other changes I want is also auto-executing all modified code blocks on file save and/or when the cursor moves out of it, auto-executing dependent blocks when their dependency changes (e.g. blocks full of constants) or marking blocks as stale. But I will make suggestions to improve these things in later emails, once I know what I want.

Hello Greg,

Agreed, just yesterday I must have pressed C-c C-c "yes" three times a minute evaluating an embedded Octave script. The current default configuration is not pleasant at all.

Hello Ihor,

> Then, what about the following:
> 1. Set org-confirm-babel-evaluate globally to t
> 2. In the files you maintain, you can always put
>    file-local/directory-local value of org-confirm-babel-evaluate to
>    nil.
> 3. We can modify org-babel-confirm-evaluate _function_ to accept four
>    possible answers: yes, no, yes for all in buffer, no for all in
>    buffer. The extra 2 options will set buffer-local value of
>    org-confirm-babel-evaluate in the current Emacs session

Don't know about option (1), (2) seems insecure at first glance, for the reasons mentioned above. (3) sounds good (yes/no/always/never?) and what I want.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Thu, Sep 08, 2022 at 12:34:25PM +0000, Fedja Beader wrote:
> Hello Richard, Ihor and Steven,
> 
> I'm aware that file-local variables exist, but it seems that
> all documentation for them put them *into the file*, which is not secure for files downloaded from the internet. What is to stop a malicious file from setting an "yes, execute me automatically" variable?

While loading the file, only "safe variables" are set without
warning (actually it's a bit more complex: specific variable-
value pairs can be marked as "safe".

See e.g. "12.12 File Local Variables" in the elisp manual.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Ihor Radchenko]

Fedja Beader <fedja@protonmail.ch> writes:

> I'm aware that file-local variables exist, but it seems that
> all documentation for them put them *into the file*, which is not secure for files downloaded from the internet. What is to stop a malicious file from setting an "yes, execute me automatically" variable?

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.

> Anyway, the point of my email was to suggest a change to org-mode such that it provides a pleasant out-of-the-box user experience for people like me. I want to use org-mode as a python/octave/R/whatever interactive notebook without having to spend several days learning elisp and the internal workings of Emacs. I have spent these days, days that could be better (sorry!) used working on actual projects of mine. But I spent this time and the time to articulate what I want and to write these emails in the hope that I will be the last person having to do so. I would also like to suggest org-mode to other people instead of Jupyter notebook without having to add "oh, btw, you might want to add these three pages of alien code to your init.el to make it usable".

I am sorry if any of the answers to your suggestion sounded hostile.
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.

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.

> To go a bit further off-thread, this change might seem unnecessary. However, the other changes I want is also auto-executing all modified code blocks on file save and/or when the cursor moves out of it, auto-executing dependent blocks when their dependency changes (e.g. blocks full of constants) or marking blocks as stale. But I will make suggestions to improve these things in later emails, once I know what I want.

Feel free to do so. Suggestions are always welcome.

> Hello Ihor,
>
>> Then, what about the following:
>> 1. Set org-confirm-babel-evaluate globally to t
>> 2. In the files you maintain, you can always put
>>    file-local/directory-local value of org-confirm-babel-evaluate to
>>    nil.
>> 3. We can modify org-babel-confirm-evaluate _function_ to accept four
>>    possible answers: yes, no, yes for all in buffer, no for all in
>>    buffer. The extra 2 options will set buffer-local value of
>>    org-confirm-babel-evaluate in the current Emacs session
>
> Don't know about option (1), (2) seems insecure at first glance, for the reasons mentioned above. (3) sounds good (yes/no/always/never?) and what I want.

(1) is what Org uses by default. I mentioned it just in case if you have
org-confirm-babel-evaluate set to nil. (Many people do use this unsafe
setting).

(2) Is safe because file-local nil value of org-confirm-babel-evaluate
    will trigger Emacs to show you a warning, as I described earlier.

(3) Let me elaborate a bit.

Yes-for-all/No-for-all may be implemented in multiple ways:
- During the current org-babel-execute-buffer call
- From now until the buffer is closed
- Forever for this file path
- Forever for this file path until the file contents is changed
- For some period of time

Moreover, the above may apply for all the src blocks in buffer or just a
particular src block.

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:

yes/no (each src block)
Yes/No (all src blocks in current org-babel-execute-buffer cal)
* (until the buffer is closed)
! (until the buffer is closed and in the next 30 days, as long as the
  buffer contents is not changed)

WDYT?

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

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

[Fedja Beader]

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

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

[Ihor Radchenko]

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

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

Summary:

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

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

[Greg Minshall]

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

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

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

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

All the points listed here seem reasonable at various levels. However, I
do think we need to be careful not to go too far in the other
direction. If the user wants a foot gun, they should be allowed to have
one, we should not give them one by default though.

There are valid use cases for a configuration which does not require
user interaction (to answer questions on block evaluation), for example,
when you want to process many org files in a batch process without user
interaction. Likewise, I don'tg want Emacs to become too much of a
'nanny'. If I decide the code in a file is safe and permanently safe, I
want to be able to disable the queries on that file permanently. I'm
happy using local variables to do this, though I would also like a
global option as well.

With regard to long or short answers to such questions, I think the
default should be the longer yes/no, but the user should be able to set
it to y/n (i.e. same as normal Emacs behaviour). Ideally, this would
fall under the same setting as the new y-or-n facility in recent emacs
versions (replacing the old approaches like defalias). 

Finally, while I can see there is a use case for being able to have fine
grained control over individual block execution, I don't think having it
as a prompt is the correct approach. Once you have many of these blocks
in a file, that prompt will rapidly become annoying. When I've required
this level of control, I've found header arguments work fine and I'm not
sure the added complexity is worth it.

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

[Greg Minshall]

hi, Tim,

> There are valid use cases for a configuration which does not require
> user interaction (to answer questions on block evaluation), for example,
> when you want to process many org files in a batch process without user
> interaction. Likewise, I don'tg want Emacs to become too much of a
> 'nanny'. If I decide the code in a file is safe and permanently safe, I
> want to be able to disable the queries on that file permanently. I'm
> happy using local variables to do this, though I would also like a
> global option as well.

sorry, i don't think i was clear.  i wasn't suggesting changing the
behavior if =org-confirm-babel-evaluate= is =nil= (either as a
buffer-local, or globally).  the trigger for prompting for "[y,n,Y,N,?]"
or long/short some such would be if it were =t= (i think?).

> With regard to long or short answers to such questions, I think the
> default should be the longer yes/no, but the user should be able to set
> it to y/n (i.e. same as normal Emacs behaviour). Ideally, this would
> fall under the same setting as the new y-or-n facility in recent emacs
> versions (replacing the old approaches like defalias).

ah, i didn't realize there was this configuration possibility.  that
makes sense.  thanks.

> Finally, while I can see there is a use case for being able to have fine
> grained control over individual block execution, I don't think having it
> as a prompt is the correct approach. Once you have many of these blocks
> in a file, that prompt will rapidly become annoying. When I've required
> this level of control, I've found header arguments work fine and I'm not
> sure the added complexity is worth it.

last time i tried to export a file with no buffer-local setting of
org-confirm-babel-evaluate, i was prompted on each code block.  and,
yes, it *is* annoying!  eliminating this behavior, while "preserving a
query", is what i find attractive in Fejda's proposal.

i apologize that i'm not sure of the header argument override?

but, still, i wouldn't argue for any new per-src-block-level
configuration.

cheers, Greg

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

[Rudolf Adamkovič]

Greg Minshall <minshall@umich.edu> writes:

> - "always this buffer" [Y?]

I would deeply appreciate this option for my Org notebook that contains
two kinds of source blocks: (1) workers for on-demand execution and (2)
reproducible examples for anytime execution.  I cannot figure out how to
make Org work with both, meaning it would execute just the reproducible
examples on 'org-babel-execute-buffer', leaving the workers alone.  As a
workaround, I configure workers with ':eval query' and then lean against
the 'n' key during 'org-babel-execute-buffer'. :)

Rudy
-- 
"Be especially critical of any statement following the word
'obviously.'"
-- Anna Pell Wheeler, 1883-1966

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Greg Minshall]

Rudy,

> I would deeply appreciate this option for my Org notebook that contains
> two kinds of source blocks: (1) workers for on-demand execution and (2)
> reproducible examples for anytime execution.  I cannot figure out how to
> make Org work with both, meaning it would execute just the reproducible
> examples on 'org-babel-execute-buffer', leaving the workers alone.  As a
> workaround, I configure workers with ':eval query' and then lean against
> the 'n' key during 'org-babel-execute-buffer'. :)

i'm a bit unclear.  does your (single?) Org notebook consist of *one*
file (and thus, [normally? always? my ignorance precedes me], one
buffer), or two files (thus, two buffers).

in the former case (one buffer), i don't know if these proposals will
help.  though, maybe as they are flushed out (precedence of the
buffer-local and/or global-local with header line constructs), it would?

in the latter case (two buffers), then, yes.

cheers, Greg

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

[Rudolf Adamkovič]

Greg Minshall <minshall@umich.edu> writes:

> i'm a bit unclear.  does your (single?) Org notebook consist of *one*
> file (and thus, [normally? always? my ignorance precedes me], one
> buffer), or two files (thus, two buffers).

One file, two kinds of "src" blocks.

> in the former case (one buffer), i don't know if these proposals will
> help.  though, maybe as they are flushed out (precedence of the
> buffer-local and/or global-local with header line constructs), it
> would?

Interesting.  Suppose I have 'org-confirm-babel-evaluate' set to 'nil'
and I answer "no to all" during 'org-babel-execute-buffer'.  I would
expect that to mean "answer 'no' to every :eval query" block and execute
the rest as usual.  If so, that would save me from having to answer "no"
dozen times.  Good point!

Rudy
-- 
"I love deadlines.  I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt, 2002

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

[Max Nikulin]

On 22/09/2022 03:56, Rudolf Adamkovič wrote:
> Greg Minshall writes:
> 
>> i'm a bit unclear.  does your (single?) Org notebook consist of *one*
>> file (and thus, [normally? always? my ignorance precedes me], one
>> buffer), or two files (thus, two buffers).
> 
> One file, two kinds of "src" blocks.
> 
>> in the former case (one buffer), i don't know if these proposals will
>> help.  though, maybe as they are flushed out (precedence of the
>> buffer-local and/or global-local with header line constructs), it
>> would?
> 
> Interesting.  Suppose I have 'org-confirm-babel-evaluate' set to 'nil'
> and I answer "no to all" during 'org-babel-execute-buffer'.  I would
> expect that to mean "answer 'no' to every :eval query" block and execute
> the rest as usual.  If so, that would save me from having to answer "no"
> dozen times.  Good point!

Since `org-confirm-babel-evaluate' may be customized to a function, 
every participant of this thread may implement their preferred policies 
with no modification of Org code or even an advice to the default 
function. If proven by some usage period convenient variants emerged 
during such activity then they may be polished to handle corner cases 
(indirect buffers, etc.) and added to Org.

However some functions will likely specific to particular users, e.g. 
consider documents in some folder safe as created by the user, but 
execution of code blocks from other files are suppressed because they 
may be received from less trusted sources.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Since `org-confirm-babel-evaluate' may be customized to a function, 
> every participant of this thread may implement their preferred policies 
> with no modification of Org code or even an advice to the default 
> function.

Not that easy.
`org-confirm-babel-evaluate' only knows about currently executed src
block. It has no access to its callers, like `org-babel-execute-buffer'.
While `org-confirm-babel-evaluate' can be used to disable queries in
buffer during current Emacs session, it will be hard to do something
like "yes, for all the next queries in the current
`org-babel-execute-buffer' call".

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

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

[Fraga, Eric]

On Sunday, 11 Sep 2022 at 17:10, Ihor Radchenko wrote:
> In fact, it is very popular to replace _all_ the yes/no prompts in
> Emacs with y/n prompts.

I had to laugh.  The oldest line in my Emacs init is

    (fset 'yes-or-no-p 'y-or-n-p)           ;I hate typing...
    
and this dates back to the 80s...

(sorry for off-topic post)

-- 
: Eric S Fraga, with org release_9.5.4-768-g5bb699 in Emacs 29.0.50