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