emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cursor-color frame parameter cannot equal background-color


From: Drew Adams
Subject: cursor-color frame parameter cannot equal background-color
Date: Sun, 21 May 2006 15:24:06 -0700

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]