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

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

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

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

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

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

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

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

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

Greg Minshall 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,

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

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

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

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

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

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

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

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

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

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

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

> 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

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

Fedja Beader 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?

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

On Thu, Sep 08, 2022 at 12:34:25PM +, 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

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

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"

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

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

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

Steven, > There is a neat solution to this problem using > > * Local Variables :noexport: > > see the discussion at stackoverflow > thanks. yes, if one has to do local variables, that is a very nice

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

There is a neat solution to this problem using * Local Variables :noexport: see the discussion at stackoverflow Cheers, Steven On Wed, 7 Sept 2022 at 05:07, Greg Minshall wrote: > Fedja, > > >

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

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

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

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