Hi Max,
Thank you for the feedback. More replies in lines. Best!
Tom
> I am not sure concerning "exactly".
>
> lisp/ob-core.el:248
> `org-confirm-babel-evaluate' is called with 2 arguments. In your patch
> `org-confirm-babel-evaluate-cell' has a single argument.
You're right, and in point of fact I should have retained the structure
exactly because in other contexts I have thought about ways to use
other languages in contexts like that. At the moment everything is
elisp so I dropped the argument, but that is clearly a mistake.
> It seems, you do not change defaults. Could you, please, provide an
> example of configuration that is less annoying, but still safe?
#+begin_src elisp :results none
(setq-local
org-confirm-babel-evaluate-cell
(lambda (lang body)
(ignore lang)
(let ((rb (read body)))
(not ; aka (unless condition t)
(or
(member rb
'((or)
(and)
;; add more forms that are known safe here
))
(and
(eq (car rb) 'identity)
(let ((v (cadr rb)))
(or
(symbolp v)
(stringp v)
(numberp v)
))))))))
#+end_src
#+header: :var v1=(or) v2=(and) v3=(identity nil)
#+header: :var v4=(identity default-directory) v5=(identity #o0755)
#+header: :var v6=(identity "not sure why you would want to do this")
#+header: :var v7=(identity (concat "this" "will" "fail"))
#+header: :var v8="reminder that strings are ok"
#+begin_src elisp
(mapcar
#'list
(list v1 v2 v3 v4 v5 v6 v7 v8))
#+end_src
> I was thinking if it is possible to collect requests to confirm and to
> allow the user to decide for the whole bunch of expressions and code
> blocks. Besides implementation issues, there is a question concerning UI
> that will allow to inspect code to be evaluated.
Yes, in the example above I thought about including something
with a yes-or-no-p where users could quickly add forms to a
safe list some (defcustom org-known-safe-cells '()) or something
like that. A user could do that with the new machinery, and we
could do the same for the default implementation. I think that
is the next step once we get the basics in place.
> Calling convention for the case of function value is not described. If
> it is really the same as for `org-confirm-babel-evaluate' then this user
> option should be mentioned in the docstring.
When I correct the function signature to actually match
I will make a note in the docstring.
> :package-version instead of :version?
I think because org is part of emacs core we use the emacs version?
I see "24.1" included with other org defcustoms.
> Is there any reason to not use the :safe property of `defcustom'? I see
> that you take definition of `org-confirm-babel-evaluate' as a template
> so I wonder if there is some particular reason or the original code was
> just written before introducing of :safe.
I'm guessing that it was written before :safe, but don't
know for sure. A systematic cleanup of stuff like that
could come after this maybe?
