[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: Wed, 12 Dec 2012 09:33:37 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Bastien <address@hidden> writes:

> Hi Eric,
> Eric Schulte <address@hidden> writes:
>> This is refactoring not bug fixing.  The most important impact is that
>> this will provide for simpler requires by the files implementing support
>> for particular languages.  Rather than having to do piecemeal requires
>> of those portions of the Babel infrastructure which may be needed
>> locally they can simple (require 'ob) and bring in all of the Babel
>> support as a single unit.
> I agree with the simplification if it does not involved creating
> ob-core.el and ob-customs.el.  Merging ob.el and ob-tangle.el (and
> perhaps ob-eval.el and ob-comint.el) is a good simplification option

This change *will* create ob-core.el, however I do think that is right
and proper.  Here's what the require structure of the core ob files will
look like after this change.

Attachment: babel-requires.png
Description: PNG image

The use of a ob-core file is necessary to avoid circular requires.  If
Emacs Lisp provided for actual modules which could be split across
multiple files we could simply have every core ob file as part of the
same module.  However given the limitations of Emacs Lisp as a language,
I think this is the cleanest approach providing for both separation of
functionality across files, and simple requiring from the outside.

>> Finally this consolidates Babel defcustoms into ob.el where they will be
>> more immediately brought into scope, and are more easily maintained.
> Yes, if you merge the files; otherwise, I'd stick to the namespace 
> rule: defcustoms belong where their namespace indicate they belong.

Agreed.  I won't consolidate the defcustoms.  As long as we're requiring
all of the files in which they live this should not be a problem.  Also,
I agree that future maintenance is eased by keeping defcustoms alongside
the code in which they are used.

Eric Schulte

reply via email to

[Prev in Thread] Current Thread [Next in Thread]