Paul> I don't understand. What do you mean by "fix it throughout Paul> Custom"? It seems to me that the problem exists only in Paul> faces.el. The problem is that Custom doesn't understand specifiers at all. If Custom used specifiers correctly, none of this would be a problem. (I don't mean that colors and/or fonts would never be weird; I mean that we would fix those problems using calls to the Custom API, not by patching XEmacs's core LISP functions.) Doing this at the level of faces.el bypasses Custom[1] completely and therefore Custom may find itself be able to make changes requested of it by users (Custom has a completely independent implementation of tag sets, unfortunately). If so, someone will have to come back and redo this code, or the Custom code. This is especially crucial for Mule users, because Custom doesn't understand that the 'font property of faces is magic. If the registries---ie, languages---of two different fonts are different, one font should not override the other since they apply to different regions of the Mule character space. Custom used to simply trash all non-ISO-8859-1 font information (using reset-face); now (if I understand what Jan has done correctly) it saves that information, but can't change it. Someday (soon, I hope) somebody is going to fix this. I don't know without a careful analysis whether your patch would interfere with this improvement or not. Many of the functions in faces.el were once part of the Custom superstructure IIRC. One thing I just noticed that bothers me is that you have usurped the TAG-SET argument of the specifier functions for just one class of tags: the device tags. However, there are several others, including visual and user-defined, and I think that you should allow for the possibility that somebody (in particular, Mule programmers) will want to pass arbitrary tag sets. I don't know that it would be a problem, but have you considered this possibility? Paul> Or, are you saying the semantics of make-face-bold, etc. are Paul> not clearly enough defined? Is this where Paul> FSF-compatibilities comes in? Yes. If you look at the comments in the LISP sources and Changelogs, you'll see that nobody is yet sure what belongs to Custom and what belongs to XEmacs. Nobody is willing to take ownership of it; I don't have the time to get enough understanding of Custom, the people who know Custom don't really understand Mule or in some cases specifiers, and they don't have time to study it either. I may be completely wrong about this, your patch may be safe and effective and The Right Stuff. However, I also know from personal experience that changes to this code are likely to result in extreme frustration for Mule users, as XEmacs can become completely[2] wedged in a state with unreadable fonts. Since many X servers scale even bitmap fonts by default, and since most Asian character sets come in only two or three sizes, it's quite possible to end up with something completely illegible. So I strongly advocate caution until somebody who knows what they're doing works on this code. Footnotes: [1] I think, see below for the ambiguity of the module <-> file relation. [2] You can change it using Lisp, but not with any of the user tools like Custom. -- 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."