"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: I'm thinking 21.0/21.1 solutions here. Unless you think it is better to tell Mule users not use customize until it has been tamed. I just looked at the FSF 20.3 source at ftp.ifi.uio.no and this part of their face-spec-set (modify-face face '(nil) '(nil) nil nil nil nil nil frame) looks almost like an reset-face to me. Note that from the look of it FSF Emacs simply does not implement the font name part of custom! (and thus do not have these problems). Currently ALL tag sets are device tags. See below What I mean is the following: a tag set is a filter. Effectively it is not the complete specifier that is used when looking for a font-instance for display but it is just those parts that have the tags associated with the device as a subset of the tag set (with a special case for nil). Therefore you can add things like 'default and 'mule-font for other uses but XEmacs thinks they are device tags. What I would like is that this mechanism is generalized as follows. I would like that not only the device locale is associated with a tag set but also the other locales. Then when matching it is not the device tags that are used as a filter, but the current locale's. For instance the customize 'dark and 'light spec-tags depend on the background of the default font in that window and are therefore window specific. This would allow complete implementation of custom-specs in terms of specifiers. The problem with this is doing it efficiently. Currently tags are aggressively cached at device level. The computation is really only done at device creation time and when defining new tags. Both of these are rare events. Creation of buffers and windows occurs much more often, therefore you need a much smarter cache. Sorry I missed that. He should allow passing a list (this should be easy). Just ditch the '(list func-tag) and do it at an higher level. No but Paul has real problems that need to be fixed. His setup might be rare now but it might not be in the future. This does seem the right way to fix that. You have settings that are valid only for a particular type of device so you add a tag set to reflect that. The current code is just a cop out. Jan