From: Eric Schulte <schulte.eric@gmail.com>
To: Bastien <bzg@altern.org>
Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-orgmode@gnu.org
Subject: Re: babel perl issue
Date: Wed, 12 Dec 2012 09:33:37 -0700 [thread overview]
Message-ID: <87obhzcjrs.fsf@gmail.com> (raw)
In-Reply-To: <87ip871bog.fsf@bzg.ath.cx> (Bastien's message of "Wed, 12 Dec 2012 17:23:59 +0100")
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Bastien <bzg@altern.org> writes:
> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> 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
> IMHO.
>
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 #2: babel-requires.png --]
[-- Type: image/png, Size: 58408 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1014 bytes --]
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
http://cs.unm.edu/~eschulte
next prev parent reply other threads:[~2012-12-12 16:34 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-09 10:54 babel perl issue flav
2012-12-09 11:15 ` Achim Gratz
2012-12-09 15:22 ` Eric Schulte
2012-12-09 20:34 ` Achim Gratz
2012-12-10 15:11 ` Eric Schulte
2012-12-10 15:22 ` flav
2012-12-10 15:32 ` Eric Schulte
2012-12-10 15:43 ` flav
2012-12-10 17:24 ` Eric Schulte
2012-12-11 9:05 ` flav
2012-12-11 13:45 ` Eric Schulte
2012-12-11 15:50 ` flav
2012-12-11 18:04 ` Achim Gratz
2012-12-12 6:15 ` flav
2012-12-10 17:51 ` Achim Gratz
2012-12-10 17:44 ` Achim Gratz
2012-12-10 18:13 ` Eric Schulte
2012-12-10 18:36 ` Achim Gratz
2012-12-11 14:33 ` Eric Schulte
2012-12-11 18:31 ` Achim Gratz
2012-12-12 0:22 ` Eric Schulte
2012-12-12 13:34 ` Achim Gratz
2012-12-11 18:39 ` Bastien
2012-12-12 0:25 ` Eric Schulte
2012-12-12 15:57 ` Bastien
2012-12-12 16:11 ` Eric Schulte
2012-12-12 16:23 ` Bastien
2012-12-12 16:33 ` Eric Schulte [this message]
2012-12-12 16:59 ` Bastien
2012-12-12 17:09 ` Eric Schulte
2012-12-12 17:13 ` Achim Gratz
2012-12-12 17:24 ` Bastien
2012-12-12 17:47 ` Eric Schulte
2012-12-12 18:07 ` Bastien
2012-12-12 18:28 ` Eric Schulte
2012-12-13 23:27 ` Bastien
2012-12-13 23:37 ` Bastien
2012-12-14 0:37 ` Eric Schulte
2012-12-14 9:55 ` Bastien
2012-12-14 15:57 ` Eric Schulte
2012-12-14 17:44 ` Bastien
2012-12-14 18:13 ` Eric Schulte
2012-12-14 19:11 ` Bastien
2012-12-12 18:00 ` Achim Gratz
2012-12-12 15:59 ` Bastien
2012-12-12 16:54 ` Achim Gratz
[not found] ` <CAOnk0vRL8PWS3JfuCAqcRcNa3FkM7tG3eH5w8cBdwtNrx757Xw@mail.gmail.com>
[not found] ` <1497100.pF6dAE0Itl@rainer>
2012-12-10 5:32 ` flav
2012-12-10 10:33 ` flav
2012-12-10 15:13 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obhzcjrs.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=Stromeko@nexgo.de \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.