Re: babel perl issue

[Eric Schulte <schulte.eric@gmail.com>]

Achim Gratz <Stromeko@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