From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: babel perl issue Date: Mon, 10 Dec 2012 11:13:52 -0700 Message-ID: <87obi193mn.fsf@gmail.com> References: <87a9tntr29.fsf@Rainer.invalid> <87sj7fp7om.fsf@gmail.com> <87wqwrrml2.fsf@Rainer.invalid> <87vcca9bxw.fsf@gmail.com> <87d2yhvm3c.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti7rd-0005GB-4d for emacs-orgmode@gnu.org; Mon, 10 Dec 2012 13:14:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ti7rY-0006sW-2Q for emacs-orgmode@gnu.org; Mon, 10 Dec 2012 13:14:01 -0500 Received: from mail-ia0-f174.google.com ([209.85.210.174]:52457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti7rX-0006sK-Uc for emacs-orgmode@gnu.org; Mon, 10 Dec 2012 13:13:56 -0500 Received: by mail-ia0-f174.google.com with SMTP id y25so5250364iay.5 for ; Mon, 10 Dec 2012 10:13:55 -0800 (PST) In-Reply-To: <87d2yhvm3c.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 10 Dec 2012 18:44:07 +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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > Eric Schulte writes: >> Using this method of requiring languages, >> >> ;; emacs-lisp >> (org-babel-do-load-languages >> 'org-babel-load-languages >> '((perl . t))) >> >> Works for me without issue when called from a fresh emacs (-Q). This is >> the recommended way of adding support for a new language and should work >> for the OP. > > Why should this be preferred over simple customization of > org-babel-load-languages? The `org-babel-do-load-languages' function handles the loading of the language-specific files as well as the removal of the evaluation functions defined by those files when languages are deactivated. This removal requires un-binding those functions. > I see no reason to have users add code to .emacs just for selecting > which Babel languages to use. > Note that if `org-babel-load-languages' is set through the customization interface then `org-babel-do-load-languages' will be called as above (see the :set keyword argument to the defcustom of `org-babel-load-languages') so it is not necessary for a user to add anything to their .emacs. > >> The two fixes seem to be either to either (1) add (require 'ob-tangle) >> to all current and new language specific files, or (2) merge ob-tangle >> into ob.el, so that they are both loaded by (require 'ob). It is >> unfortunate that because of the recursive require there is no way to >> separate a single require'd entity across multiple files. >> >> Option (2) seems most clean to me. Unless anyone has a better idea I'll >> make this change. > > Well, option (3) is to implement option (2) first, then put all > defcustoms (together with their initializers perhaps) into separate > files instead of dispersing them into many smaller ones and require them > from the top-level files (ob.el in your case, although I personally > think that all defcustoms should be visible from the start) so that any > autoloaded function invocation will see them defined with their correct > values. The external interface is then taken care of by autoloading and > the number of requires is minimal. > So, you're suggesting moving all ob-* defcustoms into ob.el or possibly into org.el? That seems reasonable to me, although I'm hesitant to add that much code to org.el w/o a go-ahead from Bastien or a more core maintainer than myself. Specifically to the require structure of Babel. Perhaps the best solution would be to replace ob.el with a small file which requires all of the core components of Babel (e.g., ob-exp, ob-ref, ob-tangle, etc...) and move the existing ob.el to something like ob-core.el. That way the entire Babel suite may be loaded by all language specific files using a single require statement. Does that seem reasonable? Thanks, > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte