Jonas Bernoulli <jo...@bernoul.li> writes: > It used to behave like that before 51a628bc5efc from 2009, which started > turning all symbols, including nil, into strings, but without giving any > reason why that should be done. > > It has worked like this for a long time now, so reverting that is > probably not feasible in the short run. However, I feel it would > make sense to change now how nil/'() is treated. Currently it is > being treated as the symbol nil, but IMO it would make more sense > to treat it as the empty list. That could be achieved with > > diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el > index b79e47900..2b4a16aea 100644 > --- a/lisp/ob-ref.el > +++ b/lisp/ob-ref.el > @@ -199,7 +199,7 @@ (defun org-babel-ref-resolve (ref) > (org-babel-execute-src-block nil info > params)))) > (error "Reference `%s' not found in this buffer" ref)))) > (cond > - ((symbolp result) (format "%S" result)) > + ((and result (symbolp result)) (format "%S" result)) > ((and index (listp result)) > (org-babel-ref-index-list index result)) > (t result)))))))))
Looks reasonable. Could you please prepare a patch and possibly also add a test that covers your use-case to testing/lisp/test-ob.el? See https://orgmode.org/worg/org-contribute.html > In the long run you might want to consider not turning any symbols > into strings, at least not when the "regular" block as well as the > post-processing block both use elisp. This may be tricky. Introducing any kind of special case will make the code fragile. We should better make things as generic as possible. -- 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>