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

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

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-wi


From: Erik Charlebois
Subject: bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs
Date: Sun, 13 Sep 2009 23:07:19 -0700

I did a deep dive and figured out exactly what is going on.

The (set-face-background 'region "ns_selection_color") that gets run in ns-win.el adds an entry to face-new-frame-defaults for 'region with "ns_selection_color" in the background slot. This gets persisted to the temacs-generated image.

In startup.el after (command-line) (and therefore, after .emacs runs), there's a call to frame-notice-user-settings. Because the background- color has been changed, a call to face-set-after-frame-default is made. This is turn calls internal-merge-in-global-face. This function overrides local settings with the global ones in face-new-frame- defaults, which clobbers the face setting.

The reason using set-face-attribute in .emacs works and custom-set- faces doesn't is because set-face-attribute (with nil frame) sets the value in face-new-frame-defaults.

Those are the gory details. I'm not sure what the right fix is.

Erik Charlebois
erikcharlebois@gmail.com

On 2009-09-13, at 6:09 PM, Glenn Morris wrote:

Erik Charlebois wrote:

The minimal .emacs that shows the problem (extracted by digging into
the color-themes package):

(setq default-frame-alist '((background-color . "white")))
(custom-set-faces '(region ((t (:background "red")))))

The face setting is not honoured (reverts to ns_selection_color).

If I do...
(set-face-attribute 'region nil :background "red")
instead of custom-set-faces, it works fine (but color-theme uses
custom-set-faces).

Your problem sounds like this one:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2868

(which unfortunately split into many different bugs rather than being
all in the same one)

I think the underlying problem is that ns-win is doing a slightly odd
thing by calling set-face-background, and it does not play well with
customize. See also bug #3408.

The solution may be to change ns-win to use a more customize-friendly
method of changing the face, if it really needs to do that.






reply via email to

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