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