fixing `reset-face' [was: New XEmacsen ... (was Re: Who broke ...)]

Jan> [ding] Why don't we save the value of 'default' at startup Jan> time and then use that when reset-face'ing 'default. That Jan> happens to be exactly what custom needs? Because defining when "startup" occurs is a problem. The current definition is "hard-coded defaults." I guess the definition you want is "before `custom-set-face' gets called in .emacs". However, suppose I write a package truetypeify.el which adds TrueType fonts and would like to respect any previous customizations? If I have a display where TT fonts are available that gets added and truetypeify'd _after_ XEmacs initialization, all that would be lost by any future Custom-ization of 'default. But I can't do it before custom-set-face in .emacs (it gets reset immediately), and I can't use it as the default Custom 'default (not all of my displays have TrueType fonts). And because Custom is conceptually incomplete in this respect. Custom emulates a small part of the specifier interface and add one `native' (to Custom) API: setting the dark/light parameter for background, which itself hasn't been fully worked out (IMO, from the occasional complaint seen about XEmacs doing strange things with color displays with optically---as opposed to Custom-defined---dark backgrounds). As far as I can tell from the documentation, 'default is not really intended to be `reset-face'ed. Instead, the user should be able to add more and more complex specifications to 'default and have them propagated to all descendant faces. Sure this is inefficient if the user is adding specifications which cancel earlier ones, but the alternative is losing all the specifications and going back to zero every time you Custom-ize---which is exactly what specifiers were intended to avoid. Custom's current behavior is to assume (a) that it owns all faces (whatever else Custom may do, changing 'default potentially affects all faces) and (b) that face behavior it doesn't know about is irrelevant. This basically reduces specifiers to ordinary variables. Granted, I don't see many packages using specifiers to customize commonly used faces; instead most packages define their own faces for everything. Maybe specifiers should be abandoned as a good idea in search of a usable interface. But Mule (for one) does depend on specifiers being treated like specifiers, so this is not going to be easy. Also, use of something like specifiers seems to be a possible basis for the "Holy Grail" of "GUI themes" that we've been talking about in the "why do *all* defaults *always* Suck Big Time?" thread. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."