From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Babel: How to call code in one org file into another org file Date: Mon, 02 Nov 2015 08:36:54 -0500 Message-ID: <87ziyw7cax.fsf@pierrot.dokosmarshall.org> References: <87oaff82pv.fsf@pierrot.dokosmarshall.org> <87bnbf80ar.fsf@pierrot.dokosmarshall.org> <87fv0ozxku.fsf@delle7240.chemeng.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFIK-0007ug-DY for emacs-orgmode@gnu.org; Mon, 02 Nov 2015 08:37:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtFIF-0005rn-Cz for emacs-orgmode@gnu.org; Mon, 02 Nov 2015 08:37:08 -0500 Received: from plane.gmane.org ([80.91.229.3]:52562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtFIF-0005qx-6l for emacs-orgmode@gnu.org; Mon, 02 Nov 2015 08:37:03 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZtFID-0003Eu-Od for emacs-orgmode@gnu.org; Mon, 02 Nov 2015 14:37:01 +0100 Received: from pool-108-20-41-232.bstnma.fios.verizon.net ([108.20.41.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Nov 2015 14:37:01 +0100 Received: from ndokos by pool-108-20-41-232.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Nov 2015 14:37:01 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Eric S Fraga 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