[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: per-file (or, really, per buffer) allowing/disallowing code block ex
From: |
Tim Cross |
Subject: |
Re: per-file (or, really, per buffer) allowing/disallowing code block execution |
Date: |
Tue, 13 Sep 2022 06:38:37 +1000 |
User-agent: |
mu4e 1.9.0; emacs 29.0.50 |
Greg Minshall <minshall@umich.edu> 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 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].
All the points listed here seem reasonable at various levels. However, I
do think we need to be careful not to go too far in the other
direction. If the user wants a foot gun, they should be allowed to have
one, we should not give them one by default though.
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.
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).
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.
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, (continued)
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Steven Harris, 2022/09/06
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Fedja Beader, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, tomas, 2022/09/08
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/09
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Fedja Beader, 2022/09/09
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/11
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/12
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution,
Tim Cross <=
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/13
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Rudolf Adamkovič, 2022/09/19
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Greg Minshall, 2022/09/19
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Rudolf Adamkovič, 2022/09/21
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Max Nikulin, 2022/09/22
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Ihor Radchenko, 2022/09/22
- Re: per-file (or, really, per buffer) allowing/disallowing code block execution, Fraga, Eric, 2022/09/19