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

[Greg Minshall <minshall@umich.edu>]

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 may be harder for the user to "grep" to find
why some expected behavior is occurring, etc.

in the "default" setting, asking to evaluate a src block would ask:
- "yes" [y]
- "no" [n]
- "always this buffer" [Y?]
- "never this buffer" [N?]

the last two would only survive this buffer; once the buffer is closed
and re-opened, you're back to "default" (unless, of course, there's a
local variable set).

Ihor, you suggested other meanings for "yes +".  while they all are
useful, i like the simplicity of just the "always for this buffer".
and, per-src block seems overkill, and too complicated, too much state
for the user to remember (but, i'm old, so memory is *always* an issue!
:).

when the user responds "always this buffer", maybe a message that, if
they want the same behavior for future buffers of this same file, add a
local variable.

anyway, that's my 2 cents.

cheers, Greg

ps -- i'm neutral w.r.t. single letter versus word-length, completing
read, prompts [the above suggestions notwithstanding].