Tom Gillespie <tgb...@gmail.com> writes: >> What do you mean by "restore"? Were it evaluated in the past? >> May you please provide a reproducer? > > Hrm. I think I may have mixed two commit lines. It is the case that > :tangle closures used to work, but you are right, the historical behavior > when tangling closures meant that all parameters were evaluated (tested > with the block below in 27 and 28). > > #+begin_src elisp :var value=(error "oops") :tangle (or "no") > value > #+end_src
This example clearly shows that evaluating everything is a bad idea. :var has no effect during tangling anyway. > My use case is that I have blocks that I want to tangle that set :var > from e.g. the library of babel, which isn't always loaded, but which also > is not required if :tangle is no. My confusion about you patch comes from the fact that #+begin_src emacs-lisp :tangle (if (= 1 1) "yes") 2 #+end_src works just fine on main. I admit that I don't fully understand your use case. >> > -(defun org-babel-tangle--unbracketed-link (params) >> > +(defun org-babel-tangle--unbracketed-link (params &optional >> > info-was-evaled) >> >> This is not acceptable. Taking care about evaluating INFO should be done >> in a single place instead of adding checks across the babel code. If we >> go the proposed way, I expect a number of bugs appearing when somebody >> forgets to change the eval check in some place. > > I don't like the solution either. I see two potential alternatives. > 1. change the structure of the info list to indicate whether it has > already been evaluated > 2. always call org-babel-read on (cdr (assq :tangle params)) even > if it may already have been evaluated which can lead to some unexpected > and potentially nasty results. I think that instead of repeating (cdr (assq :tangle params)) we need a common API that will abstract away evaluation and modify PARAMS by side effect if necessary. Something like (org-babel-get-heading-arg :tangle info/params) > I don't think we can consolidate evaluating parameters > into one place in the general case because there are > order dependencies where a setting in one param header > should mask others (as is the case here). May you please elaborate? -- Ihor Radchenko // yantar92, 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>