emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable


From: Bastien
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Fri, 30 Dec 2022 09:52:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Thanks a lot for the detailed answer, very helpful.

> What changed: The prompt previously displayed on code block evaluation
> is now also displayed when expanding header arguments:

I see nothing in etc/ORG-NEWS that describes this change: am I missing
something?

>> Whether it changed or not, what is the problem in 9.6?
>
> The problem is that Org now displays more queries.
>
>> How does the patch solves this problem?
>
> It allows disabling these new queries about lisp evaluation outside
> code blocks without disabling code block eval confirmation completely.

Is there a real use-case for this?  

It looks like the patch fixes the "too many queries" problem by
providing a setup that is similar to what was the previous default
(i.e. only asking about code block evaluation when
org-confirm-babel-evaluate-cell is set to nil.)

But are we sure that users need to confirm header args evaluation
separately from code blocks evaluation?

IOW I have difficulties understanding when these would be relevant:

(setq org-confirm-babel-evaluate-cell nil)
(setq org-confirm-babel-evaluate t)

> I later suggested disabling the queries by default - mimicking the pre
> 9.6 behaviour yet keeping the ability for concerned users enable the
> extra confirmation.

I think that's the best route: providing, optionnally, more, while not
annoying users who don't want more.

> Yes. Ideally, we need to improve the code evaluation query. It should
> allow confirming evaluation in bulk and add some code blocks/files to
> whitelist. Similar to `org--confirm-resource-safe'.

I see, indeed.

> A concern have been expressed that more queries may annoy users and
> drive them towards setting `org-confirm-babel-evaluate' to nil globally.
> Upon doing this, the future more flexible security queries may be not
> used by such users.

The future more flexible security queries will be made visibile enough
so that users currently setting `org-confirm-babel-evaluate' to nil
will *want* to have a look at it.

>> Also, org-confirm-babel-evaluate-table-cell seems more explicit than
>> org-confirm-babel-evaluate-cell.
>
> But it will not be accurate. The query is now displayed upon executing
> `org-babel-read' -- cell refers to Elisp code "cell" here. Not to a
> table cell.

I find "cell" confusing here (as Max said earlier in the thread).  It
either refers to a table cell or, in Elisp jargon, a "cons cell" (or a
"function cell").

What about modifying `org-confirm-babel-evaluate' to allow these values:

- t      : confirm header vars *and* code blocks
- 'code  : confirm code blocks
- 'vars  : confirm vars
- nil    : don't confirm

and set the default value to 'code, while allowing concerned users to
set it to `t' -- until we have a better system for evaluation query.

WDYT?

-- 
 Bastien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]