I guess I'm saying that the whole `org-babel-lob-ingest` into `org-babel-library-of-babel` exercise should make code ready and available. Otherwise (especially with the extra `org-babel-lob-ingest` in Local Variable step I mentioned), what John Kitchin suggested with `org-babel-load-file` is just as good, i.e., LOB seems hardly worth it. My whole motivation is to avoid having to scroll through endless code blocks all on the same level, rather, to have things more modular and distributed, a bit like DDLs in MS-land.

On Sat, Oct 31, 2015 at 4:34 PM, Nick Dokos <ndokos@gmail.com> wrote:
Lawrence Bottorff <borgauf@gmail.com> writes:

> Yes, I experimented with this too -- and got it to work. But strangely, if you leave out the 
>
> # eval: (org-babel-lob-ingest "./a.org")
> # eval: (org-babel-lob-ingest "./b.org")
>
> lines and do a regular `org-babel-lob-ingest` (or  C-c C-v i) on those
> two files -- it doesn't work. Rather bizarre behavior, IMHO.
>

I think you have some misconceptions about what org-babel-lob-ingest
does. All it does is go through the file and add the named source
blocks in that file to org-babel-library-of-babel: it does *not*
evaluate the code blocks. So if the code block is e.g. a lisp code
block with a defun in it, the function is *not* defined, until the
code block is evaluated by org-babel: that's what org-sbe does.

> Anyway, the dream behavior for LOB would be to simply add your files to your `org-babel-lob-files` in your Emacs init, start up an org file -- and be able to simply use all the LOB
> files in your "live" `org-babel-library-of-babel` list library.
>

You can do that but again all that does is populate a list that
only org-babel knows about. You'd still need to evaluate the code
blocks in order to tell the inferior lisp process about what the
code block define.

--
Nick