Re: mh-e/mh-acros.el advices `require' incorrectly

[Bill Wohler <wohler@newt.com>]

Richard M. Stallman <rms@gnu.org> wrote:

>     What do people think about my updating lisp/Makefile.in to remove
>     lisp/mh-e/*.elc if and only if lisp/mh-e/*.el changes?
> 
> That won't help with M-x byte-recompile.  The right solution is to
> make the graph of requires acyclic, and put the macro file at the
> start of the alphabet.  Given the way the software in fact works,
> that should be totally reliable.

Thank you. I think I'm going to go ahead and bite the bullet and do just
that. I've appended a proposal I sent to the MH-E developers today.
While I don't expect you to understand MH-E, perhaps you can let me know
whether your gut says "good idea" or "bad idea" and why.

(mh-customize.el holds all of our defcustom and defface calls.
mh-loaddefs.el is the internal MH-E analog of loaddefs.el.)

1. Remove all (require 'mh-*) lines, move the provides in
   mh-customize.el and mh-e.el to the end and start from scratch ;-).

2. Make mh-utils.el a pure "utility" package. I'm thinking chunks could
   go into mh-xface.el and mh-scan.el (taking stuff from mh-e.el too).
   We would then create files for each of the modes. We now already have
   mh-search.el, so I'd propose mh-show.el and mh-folder.el, maybe
   renaming mh-comp.el to mh-letter.el for consistency. Move
   mh-modify to mh-funcs.el where it belongs.

3. Make mh-e.el a lean, mean entry point. Make it require mh-acros,
   mh-customize, *and nothing else* within MH-E. Have it define pretty
   much only mh-rmail, mh-smail, and mh-version (functions with the
   ;;;###autoload cookie) as well as a few other generic globals such as
   mh-xemacs-flag. The frequently-used commands would go into
   mh-folder.el and the rest would go into mh-funcs.el.

4. Make mh-customize require mh-loaddefs to get the function definitions
   it needs *and nothing else* within MH-E.

5. Everything else then requires mh-e.el (implicitly getting
   mh-customize and mh-loaddefs) *and nothing else* within MH-E (except
   for perhaps variable-only files like mh-buffers.el and mh-scan.el).

6. Limit scope of variables to just the file in which it is defined.
   If necessary, provide access to variables via functions that are
   found in mh-loaddefs.el.

7. Move all macros into mh-acros.el so that we can remove the defadvice
   of require in mh-acros.el.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.