>>>> "Jan" == Jan Vroonhof
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
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."