Re: Merging customize support

Ben Wing writes: Yes, but style sheets are used under a different system with a different philosophy. Web documents are by necessity loosely specified with the client filling in the details. We are implementing a low level interface and need to specify exactly what we want, and also need to be able to easily access what someone has specified. For what we're doing, segregating device specific things like font information in a specifier looks exactly right to me. I see font specifiers being much like color specifiers. It is so much better to be able to (set-face-background 'foo "rgb:30/30/30" 'x) instead of having separate face properties for RGB values, HVC values and all the other color specification methods in existence. With a font specifier a programmer can specify things for X Windows and not worry about how Windows or some new OS we support is going to react to the generic font-family property. And when we need to find out what font is being used, the font specifier is quite handy. If we ignore XEmacs-Mule, it is easy to find out what font is being used in a window, and to find out if the font is window/buffer/frame/device-type specific. This looks a whole lot harder without a font specifier, and without constraints on the face properties that relate to the font specification. I appreciate that a style-sheet like interface is useful; giving the system a vague specificationa and letting it fill in the details is quite handy. But I don't think hacking together fonts and faces is the best way to achieve that flexibility. I think that it would be better to create a higher level construct for this purpose if we need one. Yes, but it is time for this kind of wholesale rejiggering to stop. New ideas are good, but the world keeps running thanks to day-to-day compatibility. We are past the point where we can claim that the product is so new that we won't hurt many people by radically changing the APIs. We passed that point years ago.