My plans for the next few weeks.

April 27, 2001

1. Get my `working' workspace reviewed and checked in.  Fix or attempt to fix the critical quit mechanism.
2. Merge my mule workspace up to latest trunk version.   Run with it awhile and check its working-ness. (As of April 27, it builds and runs OK, merged up to a few weeks ago.) Tag the current place in the trunk.  Switch over to mule-21-5; merge with Ikeyama's changes.  Once I'm satisfied with its working-ness, check them in
3. Look through the code and see if I can reconstruct what wasn't working when I left off. Check out various international features to see if they work.  Make sure it's quite stable.  Begin reviewing code for incompleteness and constructing ChangeLogs.
4. [at the same time as 3] Finish up my `fixup2' [size_t/unsigned -> int] workspace.  The changes have been made and it works, but I still need to make new sizeof[] and str[] functions and un-encapsulate the various encapsulated system calls.  Check this in.

Side projects [not to occupy more than 10% of my time!]:

1. The package aliases.  I have a long list of authors and maintainers constructed from grepping through the package tree.  Do some more work on this and fix up my Emacs Lisp commands to generate sets of aliases.  Get these all put in (the really questionable ones should be put in a separate section from the more certain ones).  Set something up where everything to these aliases gets archived. (Stephen, help!)  Write to all the maintainers asking for improvements.  Announce to the world.
2. behavior.el.  This is an attempt to create a single conceptual framework for enabling and disabling features, such as are provided by various packages.  Currently, each such feature has some ad-hoc way of turning it on and off.  This mechanism allows you to turn the features on and off just knowing the feature's name. (I use the term "behavior" to avoid the already overloaded term "feature".) The framework is there, in a rudimentary way, but it needs to be integrated with Custom so that a behavior can be turned on or off and this state saved out for future sessions.  A menu interface also needs to be designed and implemented, as well (of course) as a great number of behaviors added.  Perhaps this latter piece of work can be distributed somewhat by mailing to the various package authors/maintainers and to xemacs-beta, presenting the interface and asking for code written for the maintainers' packages or (in the case of xemacs-beta) the packages that particular beta testers use frequently and thus know how to use.  People sending code will not be required to put it in the right form, although this is of course preferred.