From: Greg Minshall <minshall@umich.edu>
To: Tim Cross <theophilusx@gmail.com>
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 07:47:55 +0300 [thread overview]
Message-ID: <589198.1663044475@archlinux> (raw)
In-Reply-To: <86r10g9ufs.fsf@gmail.com>
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
next prev parent reply other threads:[~2022-09-13 4:48 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
2022-09-13 4:47 ` Greg Minshall [this message]
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=589198.1663044475@archlinux \
--to=minshall@umich.edu \
--cc=emacs-orgmode@gnu.org \
--cc=fedja@protonmail.ch \
--cc=theophilusx@gmail.com \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).