Re: XEmacs 21.4.5 "Civil Service" is released.

Peter> the whole thing or just the fonts stuff for now ?? The faces code. IIRC, primarily faces.el (Customize has infested the lower-level code), cus-face.el, and cust-edit.el. The primary sticking points right now are 1. Customize is completely unaware of character set registries, for sure under X and maybe Windows too. 2. Customizations that involve frobbing font specifications (deriving bold and italic versions in particular) for some reason often fail. 3. Customize generally assumes that it owns the faces, lock, stock and barrel, and therefore may reset faces any time it wants to. This caused immense pain to users of non-iso-8859 fonts. The "fix" was to make Customize more careful about when it does such a reset. 4. My theory is that all of the above are due to the fact that Customize duplicates many aspects of XEmacs specifiers. Only with the recent changes mentioned in 3. did Customize become at all aware of specifier tags, for example. So for the moment an audit of the correspondence of Customize data structures and transformations from Customize form to XEmacs native form seems the way to go. My personal opinion (which is as yet backed up by zero lines of code, so take it with a grain of salt) is that Customize should be reimplemented from the ground up to take advantage of specifiers, something like a. Customize should store its specifications in specifiers. It is claimed that some of the things that Customize can handle are not supported by specifiers; if so the specifiers themselves may need to be revamped. That would be for 21.5 and later. But specifiers are really flexible, and certainly can (very inefficiently) emulate ordinary variables. So I suspect that may not be true. b. Customize's specifications would be marked by a special specifier tag, say 'custom. (See define-specifier-tag.) This would be redundand for ordinary variables, but it would allow Customize to operate directly on variables that are already specifiers, such as most face properties. c. This might allow a nearly trivial implementation of Custom themes by simply adding a theme-specific specifier tag. With the exception of changing the C-level specifier implementation, all of this can be done at the Lisp level. So I would suggest that it be implemented as a new-custom (or pb-custom, if you like :-) package that can be used separately by 21.4 (and even 21.1), and later be integrated into the core. Note that this implies the coexistence of the older custom and new-custom stuff, because custom.el at least is dumped into the XEmacs binary by default. Also, there's no reason to change the Customize UI and high-level APIs, just the "back end". -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.