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
>
>
>