Contribution of a :confirm-evaluate flag to src blocks

Contribution of a :confirm-evaluate flag to src blocks

[Mackenzie Bligh]

[-- Attachment #1.1: Type: text/plain, Size: 955 bytes --]

Hi All,

First time contributing here, so apologies if I haven't gotten this quite
right. As part of my employment I have an org document I have written
contains a number of restclient and bash code blocks. The results of some
of these src blocks are fed into other src blocks, and having to input "y"
multiple times when trying to hit a REST api quickly became cumbersome. I
also found the method of supplying a new org-confirm-babel-evaluate to
disable the "ask to execute" behavior on a per language basis to be too
crude. Therefore, I would like to introduce a new flag for src blocks
":confirm-evaluate", where a value of "n", "no", "f", or "false" will
disable the "ask to execute" behavior for that specific block. I believe
that this is a safer behavior compared to disabling "ask-to-execute" on a
per language basis, and adds convenience to src blocks for literate
programming. Thanks for your time, and I welcome any feedback!

Sincerely,

Mack

[-- Attachment #1.2: Type: text/html, Size: 1212 bytes --]

[-- Attachment #2: 0001-ob-core.el-Add-confirm-evaluate-flag-to-src-blocks.patch --]
[-- Type: application/x-patch, Size: 1781 bytes --]

Re: Contribution of a :confirm-evaluate flag to src blocks

[Kyle Meyer]

Hi Mackenzie,

Mackenzie Bligh <mackenziebligh@gmail.com> writes:

> First time contributing here, so apologies if I haven't gotten this quite
> right.

Great, thanks for sending the patch!

> The results of some
> of these src blocks are fed into other src blocks, and having to input "y"
> multiple times when trying to hit a REST api quickly became cumbersome. I
> also found the method of supplying a new org-confirm-babel-evaluate to
> disable the "ask to execute" behavior on a per language basis to be too
> crude. Therefore, I would like to introduce a new flag for src blocks
> ":confirm-evaluate", where a value of "n", "no", "f", or "false" will
> disable the "ask to execute" behavior for that specific block.

I'm not much of a Babel user, but I wonder whether a better option would
be to extend :eval with a value that means "eval but don't query".
org-babel-check-confirm-evaluate could then consider this when binding
`query'.  That seems like it would serve the same purpose while avoiding
adding a new header argument.

What do you think?

-- 
Kyle

Re: Contribution of a :confirm-evaluate flag to src blocks

[Mackenzie Bligh]

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

Hi Kyle,

I didn't think of that, but that's a really good idea! Do you have any
suggestions for the name of such a value?

On Wed, Jul 17, 2019 at 9:09 PM Kyle Meyer <kyle@kyleam.com> wrote:

> Hi Mackenzie,
>
> Mackenzie Bligh <mackenziebligh@gmail.com> writes:
>
> > First time contributing here, so apologies if I haven't gotten this quite
> > right.
>
> Great, thanks for sending the patch!
>
> > The results of some
> > of these src blocks are fed into other src blocks, and having to input
> "y"
> > multiple times when trying to hit a REST api quickly became cumbersome. I
> > also found the method of supplying a new org-confirm-babel-evaluate to
> > disable the "ask to execute" behavior on a per language basis to be too
> > crude. Therefore, I would like to introduce a new flag for src blocks
> > ":confirm-evaluate", where a value of "n", "no", "f", or "false" will
> > disable the "ask to execute" behavior for that specific block.
>
> I'm not much of a Babel user, but I wonder whether a better option would
> be to extend :eval with a value that means "eval but don't query".
> org-babel-check-confirm-evaluate could then consider this when binding
> `query'.  That seems like it would serve the same purpose while avoiding
> adding a new header argument.
>
> What do you think?
>
> --
> Kyle
>

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

Re: Contribution of a :confirm-evaluate flag to src blocks

[Kyle Meyer]

Mackenzie Bligh <mackenziebligh@gmail.com> writes:

> Do you have any suggestions for the name of such a value?

I tried to avoid being responsible for a poorly chosen name :]

"'yes' or 'always'" pairs well with the existing "'no' or 'never'", but
I suppose that risks users not realizing that it implies not querying.
Perhaps 'eval-no-query', 'eval-without-query', or just 'without-query'?

Re: Contribution of a :confirm-evaluate flag to src blocks

[Berry, Charles]

Gentlemen,

I think you have stepped onto a slippery slope.

Adding an :eval option that turns off confirmation queries without user intervention defeats the security purpose stated for `org-confirm-babel-evaluate'.

Likewise, adding a new header argument that turns off such checks may have pernicious effects.

A better option IMO is to use existing features of babel to accomplish the end you desire. 

A simple option is to have a src block that let binds org-confirm-babel-evaluate to nil, then navigates to and executes another src block that contains noweb statements that execute other blocks. The user is prompted just once and the global behavior of `org-confirm-babel-evaluate' is unaltered.

There are many ways to achieve this kind of behavior and/or fine tune the prompting behavior with existing babel capabilities.

HTH,

Chuck

p.s. I do not get what is `too crude' about using `org-confirm-babel-evaluate'. Maybe an ECM would help others understand what motivates this judgment.

> On Jul 18, 2019, at 12:21 PM, Kyle Meyer <kyle@kyleam.com> wrote:
> 
> Mackenzie Bligh <mackenziebligh@gmail.com> writes:
> 
>> Do you have any suggestions for the name of such a value?
> 
> I tried to avoid being responsible for a poorly chosen name :]
> 
> "'yes' or 'always'" pairs well with the existing "'no' or 'never'", but
> I suppose that risks users not realizing that it implies not querying.
> Perhaps 'eval-no-query', 'eval-without-query', or just 'without-query'?
> 
> 

Re: Contribution of a :confirm-evaluate flag to src blocks

[Kyle Meyer]

Hi Chuck,

"Berry, Charles" <ccberry@ucsd.edu> writes:

> I think you have stepped onto a slippery slope.
>
> Adding an :eval option that turns off confirmation queries without user intervention defeats the security purpose stated for `org-confirm-babel-evaluate'.
>
> Likewise, adding a new header argument that turns off such checks may have pernicious effects.

Thanks for the input.  I certainly defer to your judgment here.