I'm forwarding a bug reported by Samuel Bronson, orignally at <http://bugs.debian.org/657263>:
The header face background color initialization is based on the assumption that if `frame-background-mode' is not `dark', then the frame background color must be light. However, this variable is documented as follows:
,----[ C-h v frame-background-mode RET ]
| frame-background-mode is a variable defined in `faces.el'.
| Its value is nil
| The brightness of the background.
| Set this to the symbol `dark' if your background color is dark,
| `light' if your background is light, or nil (automatic by default)
| if you want Emacs to examine the brightness for you. Don't set this
| variable with `setq'; this won't have the expected effect.
| You can customize this variable.
Thus, if the value is nil, this variable tells us nothing about whether the background color is light or dark. In fact, it turns out that this can vary between frames within an Emacs session.
The usual way of handling this is to use `background' specs in the face definition, something like this:
| (defface link-visited
| '((default :inherit link)
| (((class color) (background light)) :foreground "magenta4")
| (((class color) (background dark)) :foreground "violet"))
| "Basic face for visited links."
| :group 'basic-faces
| :version "22.1")
I would suggest replacing the affected options in the `rst-faces-defaults' group with two options each, one for light backgrounds and one for dark backgrounds. One approach would be to allow each affected variable to accept a "(light . dark)" cons as an alternative to the single scalar it accepts now, and putting the defaults in this form rather than conditionalizing them.
Note: the easiest way to see the problem is to try using the mode in a terminal which Emacs automatically identifies as having a dark background color, with `frame-background-mode' at its default (nil) value. (Try PuTTY/pterm, for example.)
Log in to post a comment.