all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Greg Minshall <minshall@umich.edu>
Cc: Ihor Radchenko <yantar92@gmail.com>,
	Fedja Beader <fedja@protonmail.ch>,
	emacs-orgmode@gnu.org
Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution
Date: Tue, 13 Sep 2022 06:38:37 +1000	[thread overview]
Message-ID: <86r10g9ufs.fsf@gmail.com> (raw)
In-Reply-To: <1966694.1662990962@archlinux>


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.


  reply	other threads:[~2022-09-12 21:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 23:50 per-file (or, really, per buffer) allowing/disallowing code block execution Fedja Beader
2022-09-06 13:33 ` Ihor Radchenko
2022-09-06 19:05 ` Greg Minshall
2022-09-07  0:17   ` Steven Harris
2022-09-07  8:49     ` Greg Minshall
2022-09-08  5:53   ` Ihor Radchenko
2022-09-08 12:34     ` Fedja Beader
2022-09-08 17:41       ` tomas
2022-09-09  5:50       ` Ihor Radchenko
2022-09-10  0:19         ` Fedja Beader
2022-09-11  9:10           ` Ihor Radchenko
2022-09-12 13:56             ` Greg Minshall
2022-09-12 20:38               ` Tim Cross [this message]
2022-09-13  4:47                 ` Greg Minshall
2022-09-19 18:25               ` Rudolf Adamkovič
2022-09-19 19:28                 ` Greg Minshall
2022-09-21 20:56                   ` Rudolf Adamkovič
2022-09-22 14:17                     ` Max Nikulin
2022-09-23  2:31                       ` Ihor Radchenko
2022-09-19  9:23             ` Fraga, Eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86r10g9ufs.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=fedja@protonmail.ch \
    --cc=minshall@umich.edu \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.