I don't have a simple recipe starting from emacs -Q, but I think I can explain enough to make this clear. This major bug has been around since at least 2005-06-26. I believe that it was introduced after 2005-04. Because I saw it only when used with my own code and it was difficult to track down, and I figured it might have been transient (due to a temporarily bad build), and I figured that if not, someone else might discover and explain it better, I just lived with it.
The symptom I notice is this: I have a set of frame parameters for special-display frames, and other sets for frames dedicated to buffers *Help* and *Completions* (using `special-display-buffer-names' with explicit frame parameters). What happens is that the background colors of these frames are not what they should be. The culprit, it turns out, is `frame-set-background-mode', which is called from `x-create-frame-with-faces', which is called from `make-frame', which is called from `special-display-popup-frame' or whatever. As its last action, `frame-set-background-mode' iterates over all faces (that are not locally modified), calling (face-spec-set face (face-user-default-spec face) frame). The last face affected is face `default'. The final culprit is this code: (set-face-attribute 'default <:background attribute for default face>) The value of that :background attribute is the default background for `default-frame-alist' - that is, for non-special frames. So, what happens is that the `default' face for the new, special frame has its background set to the default value of the default face for the default-frame-alist. Changing the background of face `default' is tantamount to changing the background of the frame itself, so as soon as this face-attribute change is made, displaying (frame-parameters <the new frame>) shows that its background has been changed to the default background for default-frame-alist. Sorry for being so wordy. I think this boils down to the fact that face `default' should not be treated in the same way as the other faces in this regard. Whatever properties a user has assigned to the `special-display-frame-alist' or whatever should be respected. Hope you can understand this description and find the fix. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> <report-emacs-bug> Recent messages: (C:\Emacs-22-2006-03-20\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading emacsbug...done _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
