> Will it be clear to users what "cell" means in this context?
I assume the language was originally chosen with tables in mind, but I think it is clear? The one issue is that using org-babel-confirm-evaluate doesn't use the word "cell" in the yes-or-no-p prompt. > Am I wrong that, roughly speaking, the effective value is (and > org-confirm-babel-evaluate-cell org-confirm-babel-evaluate)? You are correct. Only in the case that org-confirm-babel-evaluate-cell is or evaluates to t will the yes-or-no-p be displayed _IF_ org-confirm-babel-evaluate is or evaluates to t. org-babel-confirm-evaluate (NOT org-confirm-babel-evaluate) is the function that issues the yes-or-no-p. > Should it be described in the docstring? Maybe? In the current implementation the value of org-confirm-babel-evaluate takes precedence, which I think is the correct behavior. If someone has told us that they blindly want to execute all code, but not cells, we should not change the default behavior, and thus we should execute all cells and blocks > It seems e.g. :eval query affects the latter, but not the former. :eval has no impact on cells. In fact in some files I use :eval (and this-file-done-loading "never") on some blocks that (setq this-file-done-loading) at the end to achieve only-once behavior. > If it is so then it is too complicated for me to feel firm ground > while reasoning on security. :eval has never, and cannot impact evaluation of cells, because it is specifically used to control evaluation of blocks. Similarly :eval has no interaction with any of the confirm-babel-evaluate machinery. I see one possible point of confusion which is that he :eval that you see in the code of org-babel-read is a hack to create fake info for a cell. Are you maybe looking for a file level :eval-cell option/property that would allow you to declare that you should NEVER run cells at all and also never prompt? Basically this is an option that says "treat all cells as if they and their header property are the default value". I'm fairly certain that implementing such a thing is a bad idea, for example if someone sets :dir using a cell and it is overwritten they could execute code in the wrong environment, which can lead to nasty security issues. Thus the only global option for cells that we could safely implement would have the semantics of "treat all cells as if they are (error)". > I have not decided if it is feasible to add some property to the INFO > argument passed to `org-babel-confirm-evaluate' and to put there > condition which variable should determine result. Having done so before, I would rather not touch org-babel-confirm-evaluate if at all possible. The only disadvantage is that for now when users are prompted they will not be informed that it is a cell, however from the short nature of cells the will hopefully be able to figure it out. The fact that org already jumps to the location of the cell in the file helps a lot with this. Obviously this doesn't help in a batch context, but if a user is hitting this in batch mode they are in trouble anyway.
