Ihor Radchenko writes:
>> I do wonder if the idea of a document classification model and some form
>> of heuristic algorithms to handle default document classification might
>> be useful.
>
> I do not think that we need to go in this direction.
> I doubt that we are qualified to get the
Tim Cross writes:
>> 1. Introduce a new customization `org-confirm-evaluate-safe-regexps'
>>listing regexps that are considered safe or cons cells
>>(src-body/header-arg/table/macro/diary . regexp)
>>
>> 2. Introduce a new customization `org-confirm-evaluate' that can be set
>>to
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>> P.S. Considering intense discussion around the topic, what about
>> reverting my commit from the release? We can then re-consider the whole
>> design and apply something more elaborate later.
>
> I now reverted the discussed commit.
>
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> We may, however, make `org-confirm-babel-evaluate' function value accept
>> an extra third argument - context ('code or 'vars). This will retain the
>> required flexibility without introducing an extra variable.
>
> Yes, this is an
Hi Tom,
thanks a lot for the detailed explanations: I get your point and I
understand the need. I think the revert is a good move, though, as
the solution was not really good enough.
Thanks!
--
Bastien
Ihor Radchenko writes:
> We may, however, make `org-confirm-babel-evaluate' function value accept
> an extra third argument - context ('code or 'vars). This will retain the
> required flexibility without introducing an extra variable.
Yes, this is an interesting possibility.
> P.S. Considering
Ihor Radchenko writes:
> P.S. Considering intense discussion around the topic, what about
> reverting my commit from the release? We can then re-consider the whole
> design and apply something more elaborate later.
I now reverted the discussed commit.
> P.S. Considering intense discussion around the topic, what about
> reverting my commit from the release? We can then re-consider the whole
> design and apply something more elaborate later.
I was actually going to mention that in my previous
message but forgot. I think that given the potential
Tom Gillespie writes:
>> 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
Hi Bastien,
In short, we need two variables due to the case where
a user wants to set nil for all vars and a function for code.
More replies in line. Best!
Tom
> I see nothing in etc/ORG-NEWS that describes this change: am I missing
> something?
Looks like any mention of the change is missing
On 30/12/2022 15:52, Bastien wrote:
But are we sure that users need to confirm header args evaluation
separately from code blocks evaluation?
I do not think we need to confirm header arguments *separately*, but
they should not be executed before asking users. It is not easy to
implement
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,
Bastien Guerry writes:
> I've skimmed through the discussion but I'm not entirely clear about
> the situation.
>
> Has the situation changed between 9.5 and 9.6? Tom first message
> seems to suggest it did, but etc/ORG-NEWS does not say.
I considered this change as a bugfix. Though it was more
On 29/12/2022 22:58, Bastien Guerry wrote:
From: Tom Gillespie
Date: Sat, 10 Dec 2022 12:11:17 -0800
Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
variable
...
Has the situation changed between 9.5 and 9.6?
Yes, it has. In 9.6 C-c C-c for
#+begin_src elisp :var
Ihor Radchenko writes:
> Tom Gillespie writes:
>
>> From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001
>> From: Tom Gillespie
>> Date: Sat, 10 Dec 2022 12:11:17 -0800
>> Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
>> variable
>
> Bastien, may
Tom Gillespie writes:
> From 4a78e1b5ea98dee569ff690037c661ab5c300194 Mon Sep 17 00:00:00 2001
> From: Tom Gillespie
> Date: Sat, 10 Dec 2022 12:11:17 -0800
> Subject: [PATCH 1/2] ob-core: add org-confirm-babel-evaluate-cell custom
> variable
Bastien, may you please take a look at this
Tom Gillespie writes:
> One more correction. The source of the issue is that the two values in the
> list need to be different, one for the message and one for the actual test.
> Best,
> Tom
>
> (list "emacs-lisp" cell
> '((:eval . yes)) nil (format "%S" cell)
>
One more correction. The source of the issue is that the two values in the
list need to be different, one for the message and one for the actual test.
Best,
Tom
(list "emacs-lisp" cell
'((:eval . yes)) nil (format "%S" cell)
nil nil)
By the way, while we're on bugfixes. I just noticed that (format "%S" cell)
is being used to create the fake body for info. This is incorrect because
cell is already a string at this point and this makes the behavior
inconsistent with the rest of org babel as a result. Fix below. Best,
Tom
The
Ihor Radchenko writes:
> Tim Cross writes:
>
>> Based on the information in section 17.13, how do I configure my Emacs
>> so that
>>
>> 1. All the code in the files I wrote just runs and doesn't bother me with
>> annoying execute questions.
>>
>> 2. Code in files from colleagues is shown to
Tim Cross writes:
> Based on the information in section 17.13, how do I configure my Emacs
> so that
>
> 1. All the code in the files I wrote just runs and doesn't bother me with
> annoying execute questions.
>
> 2. Code in files from colleagues is shown to me and I'm asked if it
> should be
Max Nikulin writes:
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply this patch.
>>
>> Then, we can get the old behaviour back yet allowing concerned users to
>> have more security.
>
> I am leaving it up to you. Form my point of
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I do wonder if it would be a good idea to try and document when org will
>> evaluate code in org files. This would include not just babel block
>> evaluation, but also elisp evaluation in table formulas, block header
>> arguments, file option
Tim Cross writes:
> I do wonder if it would be a good idea to try and document when org will
> evaluate code in org files. This would include not just babel block
> evaluation, but also elisp evaluation in table formulas, block header
> arguments, file option arguments and possibly other subtle
Max Nikulin writes:
> On 15/12/2022 19:25, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> I would consider reverting the commit causing user prompt for every
>>> variable.
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply
On 15/12/2022 19:25, Ihor Radchenko wrote:
Max Nikulin writes:
I would consider reverting the commit causing user prompt for every
variable.
I disagree. If anything, we can set the default value of
`org-confirm-babel-evaluate-cell' to nil and apply this patch.
Then, we can get the old
Max Nikulin writes:
>> Should we then extend `org-babel-check-evaluate' to accept "All" answer
>> in the coming bugfix release?
>
> I would consider reverting the commit causing user prompt for every
> variable.
I disagree. If anything, we can set the default value of
On 15/12/2022 16:10, Ihor Radchenko wrote:
Max Nikulin writes:
I am still in doubts if
10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey
`org-confirm-babel-evaluate'
was an unambiguous improvement. Perhaps it just forces more users to set
`org-confirm-babel-evaluate'
On Thu, Dec 15, 2022 at 09:18:14AM +, Ihor Radchenko wrote:
> Tom Gillespie writes:
[...]
> I am generally skeptical about our ability to provide universal way to
> judge if a given sexp is safe or not. It should be left to the user.
This might live in the middle of some thicket deep in
> It's purpose is also different.
> I am generally skeptical about our ability to provide universal way to
> judge if a given sexp is safe or not. It should be left to the user.
I am in complete agreement.
Tom Gillespie writes:
> Interestingly, as I was looking through my notes in
> orgstrap, I see my past self had found a macro
> org-babel-one-header-arg-safe-p which pointed to
> defconst org-babel-safe-header-args, but that is
> a const and not really user configurable.
It's purpose is also
Max Nikulin writes:
> I am still in doubts if
>
> 10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey
> `org-confirm-babel-evaluate'
>
> was an unambiguous improvement. Perhaps it just forces more users to set
> `org-confirm-babel-evaluate' to nil compromising their
Interestingly, as I was looking through my notes in
orgstrap, I see my past self had found a macro
org-babel-one-header-arg-safe-p which pointed to
defconst org-babel-safe-header-args, but that is
a const and not really user configurable. Of course
the user could cl-setf on it, but it also only
Tom, does not the following allow to achieve the same without your patch?
#+begin_src elisp :results none
(setq-local
org-confirm-babel-evaluate
(lambda (lang body)
(not
(and
(member lang '("elisp" "emacs-lisp"))
(let ((rb (read body)))
(or
> Will it be clear to users what "cell" means in this context?
I assume the language was originally chosen
with tables in mind, but I think it is clear? The
one issue is that using org-babel-confirm-evaluate
doesn't use the word "cell" in the yes-or-no-p prompt.
> Am I wrong that, roughly
On 13/12/2022 08:53, Tom Gillespie wrote:
+(defcustom org-confirm-babel-evaluate-cell t
+ "Confirm before evaluating a cell.
+This follows the same conventions as `org-confirm-babel-evaluate'."
Will it be clear to users what "cell" means in this context?
Am I wrong that, roughly speaking,
On 12/12/2022 03:27, Tom Gillespie wrote:
#+begin_src elisp :results none
(setq-local
org-confirm-babel-evaluate-cell
(lambda (lang body)
(ignore lang)
(let ((rb (read body)))
(not ; aka (unless condition t)
(or
(member rb
'((or)
Tom Gillespie writes:
> Hi Ihor,
>Here's the updated patch using :safe, and an additional
> patch for the news entry to make it easier to apply the
> core change to bugfix if needed. Best!
LGTM.
I will wait a few more days in case if other contributors have something
to say and then apply
Ihor Radchenko writes:
> I am also wondering if we should include this into bugfix.
> This is a new feature, but it appears to be important enough to be
> merged into built-in Org.
> Bastien, Kyle, any thoughts?
Sounds reasonable to me.
Hi Ihor,
Here's the updated patch using :safe, and an additional
patch for the news entry to make it easier to apply the
core change to bugfix if needed. Best!
Tom
> I am also wondering if we should include this into bugfix.
I can vouch for the fact that trying to work around this in
any
Tom Gillespie writes:
> Got it. Here's the updated patch (I think I did it correctly?).
Thanks!
You also need a NEWS entry here.
> * lisp/ob-core.el (org-confirm-babel-evaluate-cell): Added to control
> execution of cells separate from execution of src blocks, it works in
> exactly the same
:11:17 -0800
Subject: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
* lisp/ob-core.el (org-confirm-babel-evaluate-cell): Added to control
execution of cells separate from execution of src blocks, it works in
exactly the same way as org-confirm-babel-evaluate.
* lisp/ob-core.e
Tom Gillespie writes:
[...]
>> :package-version instead of :version?
>
> I think because org is part of emacs core we use the emacs version?
Please use :package-version and let the mapping be handled by
customize-package-emacs-version-alist.
> I see "24.1" included with other org defcustoms.
users.
Best!
Tom
From 54e468b60f17b54d81edafd8ee9e22311e519793 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Sat, 10 Dec 2022 12:11:17 -0800
Subject: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
* lisp/ob-core.el (org-confirm-babel-evaluate-cell): Added to control
Hi Max,
Thank you for the feedback. More replies in lines. Best!
Tom
> I am not sure concerning "exactly".
>
> lisp/ob-core.el:248
> `org-confirm-babel-evaluate' is called with 2 arguments. In your patch
> `org-confirm-babel-evaluate-cell' has a single argument.
You're right, and in point of
On 11/12/2022 03:28, Tom Gillespie wrote:
Here is a patch that improves the ergonomics and thus hopefully
the security for the recent changes to check evaluation for cells.
Tom, thank you for the patch. Frankly speaking, I was expecting this
kind of complains, but I could not suggest any
: Sat, 10 Dec 2022 12:11:17 -0800
Subject: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
* lisp/ob-core.el (org-confirm-babel-evaluate-cell): Added to control
execution of cells separate from execution of src blocks, it works in
exactly the same way as org-confirm-babel-evaluate
47 matches
Mail list logo
