From: Fedja Beader <fedja@protonmail.ch>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: per-file (or, really, per buffer) allowing/disallowing code block execution
Date: Sat, 10 Sep 2022 00:19:08 +0000 [thread overview]
Message-ID: <CMF3FCXyBgscotfCMFy5598OTDjGOklEyvUQPLPnAhmmck2mol1rFymeeGTBf1L4PBRS2H6yA_puREavAGZh5eSKDniYDjFq4Bya7g1_bYg=@protonmail.ch> (raw)
In-Reply-To: <877d2ddrkn.fsf@localhost>
> As Tomas pointed out, Emacs has a concept of safe and non-safe
> file-local variables. org-confirm-babel-evaluate in particular is only
> safe when it is set to t (query execution). If your downloaded file
> attempts to set org-confirm-babel-evaluate to nil, Emacs will show a
> warning and ask you whether you want to use this unsafe nil value.
Can this mechanism be relied upon? I see in
https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html
that user may press ! to mark everything safe. This is less effort than
the explicit "yes" required for executing a block on C-c C-c.
> I am sorry if any of the answers to your suggestion sounded hostile.
> The above does not mean that we reject your suggestion. Rather we try to
> weigh on the available options in Org and Emacs itself and then try to
> integrate the new feature into the existing concepts/functionalities.
Not at all. If anything the reply of mine might have sounded such.
Because your and Steven's initial replies focused on how to achieve this
with different user-local changes, instead of making it automatic,
it felt to me that my first email did not contain enough motivation
behind such changes and that I had to clarify it again/further.
> Note that Org mode already has a large number of customizations, which
> is why we are trying to not introduce unnecessary customizations. Too
> many options is not always a good thing.
This makes me wonder how many of us have a custom init.el for
the purpose discussed here. Surely I am not alone, and surely
having such customisation maintained in org-mode itself would
be better.
> Yes-for-all/No-for-all may be implemented in multiple ways:
> - During the current org-babel-execute-buffer call
If the user determined that it is safe to execute all blocks
once, then why would it not be safe to execute them again?
> - From now until the buffer is closed
This option is probably closest to what I want.
> - Forever for this file path
Also fine. But
1) then this would have to be stored somewhere outside
of the file, else the user would still be asked if they
want to load that unsafe local variable. Meaning that in
that case babel could just ask the user directly.
2) As I learn to use Emacs, the number of restarts
decreases, meaning that the session just lives forever.
In that case the once per open nagging of babel
is acceptable.
> - Forever for this file path until the file contents is changed
What would change the file if not the user, and if the user
already approved the existing code, why would the user
not approve their own additions to it?
> - For some period of time
Same response as above.
> Moreover, the above may apply for all the src blocks in buffer or just a
particular src block.
Going through blocks one by one and whitelisting, then executing them
seems like a reasonable course of action, so why not.
However, it might be a bit difficult to implement?
How would babel determine that a block is the same
one, even if it changes? Position in file?
> I doubt that all the options should be implemented in practice. We may
> probably just allow yes-for-all when running org-babel-execute-buffer
> but not individual C-c C-c on src blocks. I can see valid reasons to
> allow (1) in current org-babel-execute-buffer-call; (2) until the buffer
> is closed; (3) until the file contents is changed + limited by time.
> However, 3 possible options in the dialogue may be disorienting:
I would like the option to mark whole file as
trusted without having to execute all blocks in it.
> yes/no (each src block)
> Yes/No (all src blocks in current org-babel-execute-buffer cal)
all/none? always/never?
> * (until the buffer is closed)
allfornow? alluntilclose?
> ! (until the buffer is closed and in the next 30 days, as long as the
> buffer contents is not changed)
I'd prefer having to type full words,
so that it is obvious what the user meant.
next prev parent reply other threads:[~2022-09-10 0:20 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 [this message]
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
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='CMF3FCXyBgscotfCMFy5598OTDjGOklEyvUQPLPnAhmmck2mol1rFymeeGTBf1L4PBRS2H6yA_puREavAGZh5eSKDniYDjFq4Bya7g1_bYg=@protonmail.ch' \
--to=fedja@protonmail.ch \
--cc=emacs-orgmode@gnu.org \
--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).