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

[Greg Minshall <minshall@umich.edu>]

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
> 'nanny'. If I decide the code in a file is safe and permanently safe, I
> want to be able to disable the queries on that file permanently. I'm
> happy using local variables to do this, though I would also like a
> global option as well.

sorry, i don't think i was clear.  i wasn't suggesting changing the
behavior if =org-confirm-babel-evaluate= is =nil= (either as a
buffer-local, or globally).  the trigger for prompting for "[y,n,Y,N,?]"
or long/short some such would be if it were =t= (i think?).

> With regard to long or short answers to such questions, I think the
> default should be the longer yes/no, but the user should be able to set
> it to y/n (i.e. same as normal Emacs behaviour). Ideally, this would
> fall under the same setting as the new y-or-n facility in recent emacs
> versions (replacing the old approaches like defalias).

ah, i didn't realize there was this configuration possibility.  that
makes sense.  thanks.

> Finally, while I can see there is a use case for being able to have fine
> grained control over individual block execution, I don't think having it
> as a prompt is the correct approach. Once you have many of these blocks
> in a file, that prompt will rapidly become annoying. When I've required
> this level of control, I've found header arguments work fine and I'm not
> sure the added complexity is worth it.

last time i tried to export a file with no buffer-local setting of
org-confirm-babel-evaluate, i was prompted on each code block.  and,
yes, it *is* annoying!  eliminating this behavior, while "preserving a
query", is what i find attractive in Fejda's proposal.

i apologize that i'm not sure of the header argument override?

but, still, i wouldn't argue for any new per-src-block-level
configuration.

cheers, Greg