Achim Gratz <strom...@nexgo.de> 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
