Fedja Beader <fe...@protonmail.ch> writes: >> 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.
While I agree with you, most people appear to prefer a single char. In fact, it is very popular to replace _all_ the yes/no prompts in Emacs with y/n prompts. If you have an interest to change single-char prompt for buffer-local variables, feel free to file a bug report to Emacs. AFAIK, there is currently no way to customize this prompt. >> 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. I personally rarely use org-babel-execute-buffer and thus changed org-confirm-babel-evaluate to nil + added default export :eval no-export header arg. Since I run src blocks using C-c C-c, I always see what I am about to execute. >> 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? Consider a code in Org file that makes dangerous things. It may be useful to keep a query about execution just to stop and think for a moment if you really want to do it. Not for every block in buffer, but once. >> - 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. The second option is a bit more consistent with file-local variable handling and, more importantly, with `org--confirm-resource-safe' - the approach we use to download remote #+SETUPFILE. >> - 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. I was mostly thinking about a file being replaced by a new downloaded version. This is probably an overkill though. >> 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? We can use the same approach with :cache header argument. However, I feel that it is also an overkill and will rarely be needed. >> 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. If we use the approach similar to `org--confirm-resource-safe' and `org-safe-remote-resources', the safe files will be accumulated into a custom variable. That custom variable can be modified by user just as any other custom variable. >> 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. I also prefer full words, though it will be slightly inconsistent with file-local variables and remote resource query in Org. Summary: 1. We can modify `org-babel-confirm-evaluate' to allow 3 extra answers: - All (or maybe Yes, consistent with common bash script query) - None (or maybe No, consistent with common bash script query) - Always The new version can be modelled after `org--confirm-resource-safe'. Never is futile because user executing org-babel-execute-buffer will not expect the command to be ignored. Always will not be shown if `org-confirm-babel-evaluate' is not set to 'prompt or 'safe. 2. We can add C-h help buffer detailing what the answers to (similar to query-replace prompt) 3. We add a new custom variable org-confirm-babel-evaluate-safe-paths that will hold files marked safe. 4. We add two allowed values to `org-confirm-babel-evaluate': 'prompt and 'safe, just like in `org-resource-download-policy'. The default will be changed to 'prompt 5. We document changes in the manual and in the NEWS. Patches are welcome! -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
