[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] babel perl issue
From: |
Eric Schulte |
Subject: |
Re: [O] babel perl issue |
Date: |
Mon, 10 Dec 2012 11:13:52 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Achim Gratz <address@hidden> 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
- Re: [O] babel perl issue, (continued)
- Re: [O] babel perl issue, Eric Schulte, 2012/12/10
- Re: [O] babel perl issue, flav, 2012/12/10
- Re: [O] babel perl issue, Eric Schulte, 2012/12/10
- Re: [O] babel perl issue, flav, 2012/12/11
- Re: [O] babel perl issue, Eric Schulte, 2012/12/11
- Re: [O] babel perl issue, flav, 2012/12/11
- Re: [O] babel perl issue, Achim Gratz, 2012/12/11
- Re: [O] babel perl issue, flav, 2012/12/12
- Re: [O] babel perl issue, Achim Gratz, 2012/12/10
- Re: [O] babel perl issue, Achim Gratz, 2012/12/10
- Re: [O] babel perl issue,
Eric Schulte <=
- Re: [O] babel perl issue, Achim Gratz, 2012/12/10
- Re: [O] babel perl issue, Eric Schulte, 2012/12/11
- Re: [O] babel perl issue, Achim Gratz, 2012/12/11
- Re: [O] babel perl issue, Eric Schulte, 2012/12/11
- Re: [O] babel perl issue, Achim Gratz, 2012/12/12
- Re: [O] babel perl issue, Bastien, 2012/12/11
- Re: [O] babel perl issue, Eric Schulte, 2012/12/11
- Re: [O] babel perl issue, Bastien, 2012/12/12
- Re: [O] babel perl issue, Eric Schulte, 2012/12/12
- Re: [O] babel perl issue, Bastien, 2012/12/12