Daniel> Setting the *default* face from Lisp using Daniel> `set-face-property' causes this problem to show up. New Daniel> frames suddenly don't quite work. Right. Custom has a habit of clearing the default face, as well as everything else. Daniel> Earlier in the file, I also do (define-specifier-tag Daniel> 'daniel). Custom does not respect these, as far as I know; it simply trashes anything it doesn't understand. The policy of the Custom maintainers seems to be to wait until somebody complains, then add special-case code to save the problematic data as part of Custom. Daniel> Setting the default face from X resources seems to work Daniel> correctly. Nowadays Custom goes to some effort to save those. It used to trash them, too. I see Custom is still up to its old tricks. From lisp/faces.el (comments in all caps are mine): (defun startup-initialize-custom-faces () "Reset faces created by defface. Only called at startup. Don't use this function in your program." (when default-custom-frame-properties ;; Reset default value to the actual frame, not stream. (setq default-custom-frame-properties (extract-custom-frame-properties (selected-frame))) ;; like initialize-custom-faces but removes property first. (mapc (lambda (symbol) (let ((spec (or (get symbol 'saved-face) (get symbol 'face-defface-spec)))) (when spec ;; Reset faces created during auto-autoloads loading. (reset-face symbol) ;; <--- YOU LOSE LOSE LOSE ;; And set it according to the spec. ;; NOTE THAT THE SPEC IS CUSTOM INTERNAL DATA. ;; CALLING FACE MANIPULATION FUNCTIONS DIRECTLY (EG, ;; IN .emacs) DOES NOT UPDATE IT. (face-display-set symbol spec nil)))) (face-list)))) If this is called early enough in the startup sequence it is probably OK. I offer it as a typical example of the cavalier way that Custom insists on resetting faces whenever it does any manipulations. One thing you can try is to make sure that any Custom stuff is called _before_ you do your own face manipulations. However, it used to be the case that many Custom bugs of this nature would be invoked simply by changing the default face from the menu. -- 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 straight lines for? "XEmacs rules."

Yoshiki> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Yoshiki> Your comment here is clearly wrong. Huh? This is an example of the kind of thing that Custom does; Custom is far too complicated to precisely trace whether any particular function is doing evil or not. That's what I said. Yoshiki> It is called only before .emacs (or .xemacs/init.el) is Yoshiki> loaded and never called again. Doesn't satisfy the condition I just wrote? The points are that (1) Custom is _full_ of calls to reset-face type functions that destroy user customizations unless they were made through Custom. (2) Custom is _full_ of functions that masquerade as non-custom functions, making it impossible to see which code is really basic and which code is a Custom layer. lisp/faces.el in particular is a completely mixed bag of functions, most of which now expect Custom-style specifications, not XEmacs specifier-style specifications. However, this is not reflected in their names or docstrings (except indirectly via reference to "defface", which itself is a Custom interface). Yoshiki> The issue here is not the order of Custom and user Yoshiki> setting. Of course it is one of the issues. There may be others, too. But if you make sure you do your own setting after Custom does, your settings will rule. If you don't, Custom reserves the right to trash them. Always has before, and it is impossible to tell from the code in faces.el just what Custom does respect nowadays. You make exactly the same point yourself: try using Custom exclusively. Yoshiki> The problem is XEmacs tries to adjust face accroding to Yoshiki> background color of default face. This may also be a problem. I think adjusting faces with respect to the default face's background is a very bad idea as a basic function; it should be done at a very high level, such as Custom themes. At lower levels, functions should do what the user says. Yoshiki> Current model is not working too well. No, and it has been sucky for years. However, Custom does little to help; Custom has always tried to force the world into a simplified model. For example, Custom still knows nothing about non-ISO8859-* fonts. The last big Custom blowup occurred because it reset the faces anyway, despite there being data there it didn't understand. Apparently it is still doing it. I've tried to do something about it and been defeated. I just don't understand what Custom is trying to do. I doubt that's because the code sucks; anybody who has worked much with fonts and/or Mule charsets knows that this stuff is just plain hard. It's not surprising the code is hairy and hard to follow: the underlying process is, too. What I object to is the fact that Custom uses functions like `reset-face', whose documentation says "only do this if you know you want to". What has consistently been the case is that Custom has called this function behind the backs of users who definitely didn't want it to happen, but Custom didn't know any better. It really should stop doing this. -- 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 straight lines for? "XEmacs rules."

Various people who don't need personal copies and the BTS removed from address list. Shoulda done that before. Yoshiki> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Yoshiki> You don't lose here. You do. Suppose that I have customized the faces for foo-mode. Now Harry comes up with a real spiffy set of faces for foo-mode, and Taro the maintainer agrees and puts them in. I cannot easily recover that default information (for trial purposes) by temporarily removing the customization in my running XEmacs; I must reload the library or even restart XEmacs with my Custom-based customizations disabled, which may not be desirable. I don't think this is generally a problem. But we've been patching pieces of Custom for years, and these annoying little bugs still keep crawling out of the cracks between the window and the WM decorations. Yoshiki> It's not "a typical example of the cavalier way that Yoshiki> Custom insists on resetting faces whenever it does any Yoshiki> manipulations". OK, whatever. The fact is that reset-face is a customization- destroying function; I really don't see a good excuse for calling it without user interaction. Custom is making the assumption that it knows everything relevant, and that assumption is false. Yoshiki> Hmm... Then what background spec of defface is for? I'm Yoshiki> not a particular fun of it, but I think it's useful. I don't know. As I've said, I find Custom's face model limiting. I suppose it was a way to avoid figuring out how to do reliable contrast calculations (admittedly, quite unobvious). -- 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 straight lines for? "XEmacs rules."

Yoshiki> It seems you are refusing to understand what I said. No, not at all. I presented an example in which the procedure as written is _designed_ to destroy useful data. In this case it happens not to be the user's customization; it happens that the user would like to experiment with somebody else's configuration without restarting Emacs. It's still useful data, and I still see no excuse for destroying it. If it were garbage, it would get collected. But it's not. So? pdump_load is called before _anything_ is loaded and it still managed to destroy user data (namely, command line option settings). That was a design bug, too. Yoshiki> If you were referring to face-spec-reset function I Yoshiki> wholeheartedly agree. But I don't understand why you Yoshiki> ignore context and add random remarks. Because I'm not capable of fixing this particular bug; only suggesting a work-around that you say is irrelevant. What I am primarily concerned about is the future bugs that Custom is 99.44% sure to introduce due to its habit of destroying data without requesting confirmation from the user. Custom maintainers have been saying for years "we'll fix this, we'll fix that." I'm suggesting that maybe Custom should stop breaking things in the first place. On thing that LISP stands for is "Loaded In, Saved Permanently"! ;) -- 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 straight lines for? "XEmacs rules."