From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bill Wohler Newsgroups: gmane.emacs.devel,gmane.mail.mh-e.devel Subject: Re: mh-e/mh-acros.el advices `require' incorrectly Date: Sun, 15 Jan 2006 17:29:56 -0800 Organization: Newt Software Message-ID: <4375.1137374996@olgas.newt.com> References: <837.1137190309@olgas.newt.com> <87vewmifds.fsf@olgas.newt.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137375068 14676 80.91.229.2 (16 Jan 2006 01:31:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2006 01:31:08 +0000 (UTC) Cc: mh-e-devel@lists.sourceforge.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 16 02:31:03 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EyJD2-0007CB-45 for ged-emacs-devel@m.gmane.org; Mon, 16 Jan 2006 02:31:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EyJFI-0005aG-6o for ged-emacs-devel@m.gmane.org; Sun, 15 Jan 2006 20:33:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EyJEL-0004jV-8P for emacs-devel@gnu.org; Sun, 15 Jan 2006 20:32:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EyJEK-0004ik-G0 for emacs-devel@gnu.org; Sun, 15 Jan 2006 20:32:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EyJEK-0004iY-77 for emacs-devel@gnu.org; Sun, 15 Jan 2006 20:32:20 -0500 Original-Received: from [207.69.195.62] (helo=pop-altamira.atl.sa.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EyJHj-0000zh-S4; Sun, 15 Jan 2006 20:35:51 -0500 Original-Received: from h-64-105-34-218.snvacaid.dynamic.covad.net ([64.105.34.218] helo=olgas.newt.com) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EyJC1-0006kR-00; Sun, 15 Jan 2006 20:29:57 -0500 Original-Received: by olgas.newt.com (Postfix, from userid 1000) id 095DB16FD9; Sun, 15 Jan 2006 17:29:57 -0800 (PST) Original-Received: from olgas.newt.com (localhost [127.0.0.1]) by olgas.newt.com (Postfix) with ESMTP id 05B7816F5D; Sun, 15 Jan 2006 17:29:57 -0800 (PST) Original-To: rms@gnu.org In-Reply-To: "Richard M. Stallman"'s message of Sun, 15 Jan 2006 18:07:19 EST. X-Mailer: MH-E 7.85+cvs; nmh 1.1; GNU Emacs 22.0.50.1 X-Image-URL: http://www.newt.com/wohler/images/bill-diving.png Mail-Followup-To: emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49151 gmane.mail.mh-e.devel:11315 Archived-At: Richard M. Stallman 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 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.