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].
