emacs -q Put these sexps in buffer *scratch*:
1. (setq default-frame-alist '((foreground-color . "Blue") (mouse-color . "Red") (cursor-color . "Red"))) 2. (modify-frame-parameters (selected-frame) '(;;(background-color . "Black") (cursor-color . "Black"))) Eval #1. C-x 5 2 to create a new frame. The new frame's cursor color is Red Eval #2 (in the new frame). The new frame's cursor is now black - no problem. Delete the new frame. Uncomment the background-color in #2. Eval #1 again and C-x 5 2 to create a new frame. Eval #2 (in the new frame). The new frame's cursor is still red - the spec change had no effect in this regard. This is the main bug. Delete the new frame. Now comment out the mouse-color in #1, and repeat the last test (eval #1, create new frame, eval #2). The new frame's cursor is black when on text that has no face (other than default) and it is the color of font-lock-string-face when on text inside a string. This is another bug. There should be no connection between mouse-color and cursor-color. The frame spec should always be respected, no matter if that effectively makes the cursor invisible in some contexts. That is, (cursor-color . "Black") should always make the cursor black. An application where this has a negative effect uses space characters with a face that has a background different from the frame background, to make spaces visible in different ways. The application wants the cursor color to be the same as the frame's background color (black). The cursor should be visible over the space character's face, and it should be able to be the same as the frame background. The mouse-color effect makes me think that both bugs might be inadvertent - when no mouse-color spec is present the cursor color is correct except over faces. On the other hand, with mouse-color present, the effect is to prevent the cursor-color from being the same as the background color. That makes me suspect that someone might have done this intentionally, thinking it was always DTRT. If so, this is a design mistake - the frame spec should always be taken literally, not second-guessed and overridden by "smart" code. 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> <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 emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug