From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bill Wohler Newsgroups: gmane.mail.mh-e.devel,gmane.emacs.devel Subject: MH-E reorg (was: mh-e/mh-acros.el advices `require' incorrectly) Date: Sun, 29 Jan 2006 11:22:48 -0800 Organization: Newt Software Message-ID: <406.1138562568@olgas.newt.com> References: <837.1137190309@olgas.newt.com> <87vewmifds.fsf@olgas.newt.com> <4375.1137374996@olgas.newt.com> <1906.1137471641@olgas.newt.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1138562594 11493 80.91.229.2 (29 Jan 2006 19:23:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 Jan 2006 19:23:14 +0000 (UTC) Original-X-From: mh-e-devel-admin@lists.sourceforge.net Sun Jan 29 20:23:11 2006 Return-path: Envelope-to: gmmd-mh-e-devel@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F3I8e-0007oa-Si for gmmd-mh-e-devel@m.gmane.org; Sun, 29 Jan 2006 20:23:05 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 1A83E1272B; Sun, 29 Jan 2006 11:23:04 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1F3I8T-0001ik-Vi for mh-e-devel@lists.sourceforge.net; Sun, 29 Jan 2006 11:22:53 -0800 Original-Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1F3I8R-0003Ot-EH for mh-e-devel@lists.sourceforge.net; Sun, 29 Jan 2006 11:22:53 -0800 Original-Received: from h-68-165-3-12.snvacaid.dynamic.covad.net ([68.165.3.12] helo=olgas.newt.com) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F3I8O-000583-00; Sun, 29 Jan 2006 14:22:49 -0500 Original-Received: by olgas.newt.com (Postfix, from userid 1000) id 3290516FD9; Sun, 29 Jan 2006 11:22:48 -0800 (PST) Original-Received: from olgas.newt.com (localhost [127.0.0.1]) by olgas.newt.com (Postfix) with ESMTP id 2EE9816F4D; Sun, 29 Jan 2006 11:22:48 -0800 (PST) Original-To: emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net In-Reply-To: Bill Wohler's message of Mon, 16 Jan 2006 20:20:41 PST. <1906.1137471641@olgas.newt.com> 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-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Original-Sender: mh-e-devel-admin@lists.sourceforge.net Errors-To: mh-e-devel-admin@lists.sourceforge.net X-BeenThere: mh-e-devel@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Forum for the MH-E developers List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Sun, 29 Jan 2006 11:22:48 -0800 Xref: news.gmane.org gmane.mail.mh-e.devel:11429 gmane.emacs.devel:49698 Archived-At: Bill Wohler wrote: > Richard M. Stallman wrote: > > > I don't understand 100% of the plan, but it looks like a good plan > > overall. > > Thanks for the feedback. > > > 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. > > > > 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. > > > > I think these two are be necessary to solve the present problem, and > > could substantially increase the amount of change. It might be better > > not to do these changes now. > > Maybe. I'm investigating it right now since it seems that every day we > uncover a new problem associated with the current mess. It's extremely > brittle. The changes will either work or they won't. If they do, I think > it would actually add to the stability of the release to check in the > changes. I'll let you know how it goes. Hi Richard, I finished the reorganization of MH-E over a week ago, and I'm extremely pleased with the results. The developers and a few users have been smoke testing a tarball of my work directory and there are no known issues (the only issue revealed by the smoke test was a small Emacs 21 issue which was quickly fixed). I'm sorry this didn't come up sooner in the release cycle, but I'll go ahead and check in the changes since I'm definitely going to use them for the MH-E 8.0 release, the MH-E package isn't a critical part of Emacs, and I think the Emacs 22 release will be more stable with few, if any, risks. Highlights: 1. Circular dependencies are gone. 2. defadvice of require is gone; shared macros have been moved to mh-acros.el. This means that you'll never get stale macro definitions making the defadvice unnecessary. 3. I was able to delete this code *within* mh-gnus-article-highlight-citation: ;; Requiring gnus-cite should have been sufficient. However for Emacs21.1, ;; recursive-load-depth-limit is only 10, so an error occurs. Also it may be ;; better to have an autoload at top-level (though that won't work because ;; of recursive-load-depth-limit). That gets rid of a compiler warning as ;; well. (unless mh-xemacs-flag (require 'gnus-art) (require 'gnus-cite)) 4. I was able to delete this code in mh-utils.el: (eval-and-compile (defvar recursive-load-depth-limit) (if (and (boundp 'recursive-load-depth-limit) (integerp recursive-load-depth-limit) (< recursive-load-depth-limit 50)) (setq recursive-load-depth-limit 50))) 5. I was able to delete eval-and-compile tricks as in the following around mh-show-font-lock-keywords: (eval-and-compile ;; Otherwise byte-compilation fails on ;; `mh-show-font-lock-keywords-with-cite' 6. XEmacs now compiles with just three warnings (from XEmacs macros which I can't do anything about). It used to compile with *hundreds* of warnings and a handful of errors too. (Note that MH-E has always compiled clean in GNU Emacs--it is a developer requirement.) While the diffs will be large, they mostly represent functions moving from one file to another. The functional groupings are now much more cohesive and consistent and will be easier to maintain. Developers should be aware that three files will be deleted so it might be a good idea to remove lisp/mh-e/*.elc. The entry points are in different files too so users of CVS MH-E will have to run "cd lisp; make autoloads". You can accomplish both, of course, with "make bootstrap". Nine new files were added. If you're curious, here is the original plan with commentary: > 1. Remove all (require 'mh-*) lines, move the provides in > mh-customize.el and mh-e.el to the end and start from scratch ;-). Done. > 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. Done. While I moved mh-letter-mode into mh-letter.el, It still made sense to keep mh-comp.el. I also pulled the limiting code out of mh-seq.el into mh-limit.el and the threading code out of mh-seq.el into mh-thread.el. In addition, I created mh-compat.el (for compatibility defsubsts) and mh-tool-bar.el for the tool bar creation code. > 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. I made mh-e.el lean and mean, but not exactly as I described. I moved nearly all of the code into other more logical files, pulled in the defcustoms from mh-customize.el, and then just enough code to get it to compile, including mh-init.el and mh-exec.el (removing those three files as a result). The only entry point left in mh-e.el is mh-version. I moved the other entry points into their corresponding files (for example, mh-smail into mh-comp.el and mh-rmail into mh-folder.el). The result eliminates dependencies in mh-e.el, and reduces the amount of code that needs to be loaded when running, say, just mh-smail. > 4. Make mh-customize require mh-loaddefs to get the function definitions > it needs *and nothing else* within MH-E. The content of mh-customize.el was incorporated into mh-e.el and the file was removed. > 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). Done. > 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. I did this in a couple of places where it was very clearly the right thing to do, but left the vast majority of globals there were previously spread across mh-e.el and mh-utils.el in mh-e.el. > 7. Move all macros into mh-acros.el so that we can remove the defadvice > of require in mh-acros.el. Done, except that I didn't move all macros, just those that were used in more than one file. -- 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. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642