Hi Kyle, Sorry for the slow turnaround time on this one. Having now tested it, I think that your solution is a much better one for the time being, so please go ahead and apply it. From this discussion there are a number of good options for improvements in the future, but my priority would be to get the expanded version of the body passed to org-confirm-babel-evaluate asap with as few disturbances to the rest of the code base as possible. Best! Tom
On Tue, Jul 21, 2020 at 9:20 PM Kyle Meyer <k...@kyleam.com> wrote: > > Tom Gillespie writes: > > > On Sun, Jul 19, 2020 at 2:13 PM Kyle Meyer <k...@kyleam.com> wrote: > > >> An option not mentioned above is to replace (nth 1 info) with the > >> expanded body upstream of (when (org-babel-check-evaluate info) ...). > >> Modifying the body in INFO is admittedly not pretty, but it's in line > >> with what is done elsewhere (e.g., -expand-src-block, > >> -exp-process-buffer, -load-in-session), as well as with how other INFO > >> elements in -execute-src-block are handled. > > > > I considered this as well, and in fact I assumed that this is how it worked > > before I looked to see the code was actually doing. I didn't know what the > > consequences of making it work that way would be and tend to err on the > > side of not kobbering data that some other function might expect to be in > > an unmodified state. This would certainly be the most expedient solution. > > > > There would need to be a way to indicate that info should not expand noweb > > references so that :noweb no-export can get the unexpanded form. Maybe > > and optional argument =expand= that defaults to t? > > (defun org-babel-get-src-block-info (&optional light datum expand) > > ... ) > > Hmm, it looks like you're thinking of a different spot than I was > referring to. I was talking about modifying (nth 1 info) in > -execute-src-block, before the (when (org-babel-check-evaluate ...). > > Prior to commit 3b3fc520a, (nth 1 info) was modified in > -execute-src-block but after org-babel-check-evaluate and > org-babel-confirm-evaluate. That makes me think it'd probably be safe > to do again, just a bit upstream in the same function. And I don't see > a spot where modifying that element would be problematic. On the > incoming end, INFO is passed to copy-tree if it is provided as an > argument, and I don't think any of the functions that -execute-src-block > feeds INFO to would be affected. But I of course could be overlooking > something. > > On the other hand, if org-babel-get-src-block-info did the expansion, > I'd be a bit more worried about downstream effects (though I haven't > tried to trace things too closely). Also, -execute-src-block takes a > PARAMS argument, and I think that needs to be merged with (nth 2 info) > before considering whether to expand, so it seems like expanding in > -get-src-block-info would be too soon. > > Regardless of whether modifying (nth 1 info) would work, I also think > it'd be fine to instead go ahead with something along the lines of your > initial patch. In that case, the main question is whether coderefs > should be removed (as they currently are in your patch). If not, > perhaps something like below (untested) would suffice. > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index e798595bd..230706b7f 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -238,7 +238,10 @@ (defun org-babel-check-confirm-evaluate (info) > (if (functionp org-confirm-babel-evaluate) > (funcall org-confirm-babel-evaluate > ;; Language, code block body. > - (nth 0 info) (nth 1 info)) > + (nth 0 info) > + (if (org-babel-noweb-p headers :eval) > + (org-babel-expand-noweb-references info) > + (nth 1 info))) > org-confirm-babel-evaluate)))) > (cond > (noeval nil)
