Eric S Fraga <e.fr...@ucl.ac.uk> writes: > On Saturday, 31 Oct 2015 at 16:51, Lawrence Bottorff wrote: >> 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. > > But it does. There are two levels here: the babel codes and the results > of the codes. If your babel codes are emacs which define functions, > these latter functions are not available until the babel codes are > executed. However, the babel codes are now there and ready to be > executed by name. > > I would not want ingest to execute the codes for two reasons: many of > the codes do not make sense without special arguments and there may be > many such codes.
Indeed - and just to amplify this a bit, you can arrange (and it's arguably "better" if you have files whose code blocks you want to reuse) for all the relevant files to be in org-babel-library-of-babel during initialization; you do not *need* to have them added through the Local Variables trick: just add org-babel-lob-ingest calls to .emacs. You can also add the block evaluations in your .emacs, but that is probably a bad idea as Eric points out. Instead, use Local Variables with eval: (org-sbe "foo") calls to evaluate just what you need for the current buffer (and make sure that the relevant inferior process running the language interpreter is started *before* you open the file: emacs-lisp is exempt, since it's always there). The difference of opinion arises in the interpretation of "ready and available". The LOB in this case (and maybe in all cases, but I haven't used it often enough to be able to make such a statement) behaves more like an #include file in C, rather than a library of precompiled code that you link against (think libc.so or equivalent): you need to "compile" (i.e. evaluate) the code block before it becomes available to your code. -- Nick
