"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
(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))))
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.
Your comment here is clearly wrong. It is called only
before .emacs (or .xemacs/init.el) is loaded and never
called again. It is what doc-string says. I know because I
wrote this code. It is necessary to set face correctly when
defface is called from auto-autoloads.el by accident. I
believe now it is possible to write defface in dumped lisp
code but I haven't tested it yet.
One thing you can try is to make sure that any Custom stuff is
_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.
The issue here is not the order of Custom and user setting.
The problem is XEmacs tries to adjust face accroding to
background color of default face. Even if you set default
face's background to dark in .emacs, first frame is created
in light color (gray80). When you create new frame, XEmacs
finds backgrounds mode doesn't match the first frame and
reset all faces.
Some workarounds are:
1. Use custom to set face. (untested)
2. Use .Xdefaults
3. (setq frame-background-mode 'dark)
A right solution would be to implement face updating code in
C and call it when background of default face is changed.
Current model is not working too well.