bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Adrian Robert]

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

Thanks for looking into this.  Does changing the setting in ns-win.el  
to the customize-face form work?  (Not sure that's the way to go  
though.  I suspect we'll need to put some conditional code in the  
place that sets up the face.)

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Erik Charlebois]

Yes, using

(custom-set-faces '(region ((t (:background "ns_selection_color")))))

instead does work. But I'm quite hazy on the implications of that :).

Erik Charlebois
erikcharlebois@gmail.com




On 2009-09-18, at 4:57 PM, Adrian Robert wrote:

> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4381
>
> Thanks for looking into this.  Does changing the setting in ns- 
> win.el to the customize-face form work?  (Not sure that's the way to  
> go though.  I suspect we'll need to put some conditional code in the  
> place that sets up the face.)
>

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Stefan Monnier]

> (custom-set-faces '(region ((t (:background "ns_selection_color")))))

Why not change faces.el directly?


        Stefan

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Adrian Robert]

On Sep 20, 2009, at 9:37 AM, Stefan Monnier wrote:

>> (custom-set-faces '(region ((t (:background "ns_selection_color")))))
>
> Why not change faces.el directly?

I guess I'd prefer to remove this feature completely over hacking  
into faces.el.  Colors there are defined for dark and light  
backgrounds, which is not supported by the NS implementation.  It  
would be nice to allow the default system-wide selection color to be  
used under NS, but I guess if this is not being implemented on GTK /  
etc. it is not considered important by emacs users.

However, I'm wondering why OP was seeing lightgoldenrod2 at all --  
this should only be used if there is no value for AppleHighlightColor  
set in the defaults, which there should be.

Erik, what do you get from a "defaults read NSGlobalDomain  
AppleHighlightColor"?

Incidentally, another solution (posted for bug 3434) is:

(if (not (face-attribute 'region :background))
     (set-face-background 'region "ns_selection_color"))

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Stefan Monnier]

>>> (custom-set-faces '(region ((t (:background "ns_selection_color")))))
>> Why not change faces.el directly?

> I guess I'd prefer to remove this feature completely over hacking into
> faces.el.

Your call, but if you want to change the default value of the `region'
face, it should be done directly in faces.el.

> Colors there are defined for dark and light backgrounds, which
> is not supported by the NS implementation.

Why isn't it supported?

> It would be nice to allow the default system-wide selection color to
> be  used under NS, but I guess if this is not being implemented on GTK
> /  etc. it is not considered important by Emacs users.

IIUC it is supported under w32 (also be defining special color names),
so you may want to check what they do there.  I do not know if they set
the faces to use those by default.
BTW, it might be a good idea to try and use the same special color names
whenever possible.
There's no such support under Gtk currently, AFAIK, but I don't think
it's because we don't want it, but because nobody wrote the code for it yet.


        Stefan

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Adrian Robert]

On Sep 23, 2009, at 6:44 PM, Stefan Monnier wrote:

>>>> (custom-set-faces '(region ((t (:background  
>>>> "ns_selection_color")))))
>>> Why not change faces.el directly?
>
>> I guess I'd prefer to remove this feature completely over hacking  
>> into
>> faces.el.
>
> Your call, but if you want to change the default value of the `region'
> face, it should be done directly in faces.el.

Hmm, now that I see the 'type' parameter for defface, a patch is  
attached.



>> Colors there are defined for dark and light backgrounds, which
>> is not supported by the NS implementation.
>
> Why isn't it supported?

The only system-defined selection color on NS platforms is for the  
unconfigurable standard background color of white.



>> It would be nice to allow the default system-wide selection color to
>> be  used under NS, but I guess if this is not being implemented on  
>> GTK
>> /  etc. it is not considered important by Emacs users.
>
> IIUC it is supported under w32 (also be defining special color names),
> so you may want to check what they do there.  I do not know if they  
> set
> the faces to use those by default.
> BTW, it might be a good idea to try and use the same special color  
> names
> whenever possible.
> There's no such support under Gtk currently, AFAIK, but I don't think
> it's because we don't want it, but because nobody wrote the code  
> for it yet.

It looks like w32 adds system colors to a color "map" in  
w32fns.c:add_system_logical_colors_to_map ().  So they are available  
to the user when customizing.  Making some sort of alias like "system- 
selected-text-background" that window system code could map  
appropriately sounds like a good way to go.


--- faces.el.~1.446.~	2009-09-05 15:33:48.000000000 -0400
+++ faces.el	2009-09-23 23:06:19.000000000 -0400
@@ -2281,6 +2281,8 @@ terminal type to a different value."
  (defface region
    '((((class color) (min-colors 88) (background dark))
       :background "blue3")
+    (((class color) (min-colors 88) (background light) (type ns))
+     :background "ns_selection_color")
      (((class color) (min-colors 88) (background light))
       :background "lightgoldenrod2")
      (((class color) (min-colors 16) (background dark))

--- ns-win.el.~1.53.~	2009-09-22 22:32:24.000000000 -0400
+++ ns-win.el	2009-09-23 23:03:31.000000000 -0400
@@ -1075,8 +1067,6 @@ On Nextstep, put TEXT in the pasteboard;
    (interactive)
    (insert (ns-get-cut-buffer-internal 'SECONDARY)))

-(set-face-background 'region "ns_selection_color")
-


  ;;;; Scrollbar handling.

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Stefan Monnier]

>>> Colors there are defined for dark and light backgrounds, which
>>> is not supported by the NS implementation.
>> Why isn't it supported?
> The only system-defined selection color on NS platforms is for the
> unconfigurable standard background color of white.

I'm not sure we're talking about the same thing.  The lisp/faces.el
notion of dark/light background doesn't have anything to do with the
desktop's background, but with the Emacs buffers's default background
(i.e. whether the background color of the `default' face is rather
light or rather dark).

> --- faces.el.~1.446.~	2009-09-05 15:33:48.000000000 -0400
> +++ faces.el	2009-09-23 23:06:19.000000000 -0400
> @@ -2281,6 +2281,8 @@ terminal type to a different value."
>  (defface region
>    '((((class color) (min-colors 88) (background dark))
>       :background "blue3")
> +    (((class color) (min-colors 88) (background light) (type ns))
> +     :background "ns_selection_color")
>      (((class color) (min-colors 88) (background light))
>       :background "lightgoldenrod2")
>      (((class color) (min-colors 16) (background dark))

Could you add a comment explaining why you put (background light) in
the specs?  I guess it's because the ns_selection_color is (almost)
always defined with the assumption that it will be used on text
displayed on a light background., right?


        Stefan

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Adrian Robert]

On Sep 24, 2009, at 11:14 AM, Stefan Monnier wrote:

>>>> Colors there are defined for dark and light backgrounds, which
>>>> is not supported by the NS implementation.
>>> Why isn't it supported?
>> The only system-defined selection color on NS platforms is for the
>> unconfigurable standard background color of white.
>
> I'm not sure we're talking about the same thing.  The lisp/faces.el
> notion of dark/light background doesn't have anything to do with the
> desktop's background, but with the Emacs buffers's default background
> (i.e. whether the background color of the `default' face is rather
> light or rather dark).

No, we are.  The background of content panes in apps under NS (text  
editors, email readers, PDF viewers, etc.) is unconfigurably fixed to  
be white.  So the system-defined selection color will work well with  
light backgrounds, but not dark.  The patch I attached handles this  
in a reasonable way though.



>> --- faces.el.~1.446.~	2009-09-05 15:33:48.000000000 -0400
>> +++ faces.el	2009-09-23 23:06:19.000000000 -0400
>> @@ -2281,6 +2281,8 @@ terminal type to a different value."
>>  (defface region
>>    '((((class color) (min-colors 88) (background dark))
>>       :background "blue3")
>> +    (((class color) (min-colors 88) (background light) (type ns))
>> +     :background "ns_selection_color")
>>      (((class color) (min-colors 88) (background light))
>>       :background "lightgoldenrod2")
>>      (((class color) (min-colors 16) (background dark))
>
> Could you add a comment explaining why you put (background light) in
> the specs?  I guess it's because the ns_selection_color is (almost)
> always defined with the assumption that it will be used on text
> displayed on a light background., right?

Something like:

;; Region face: under NS, use the system-defined selection color
;; (optimized for the system-fixed white background of other apps),
;; if background is light.

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Stefan Monnier]

>>> --- faces.el.~1.446.~	2009-09-05 15:33:48.000000000 -0400
>>> +++ faces.el	2009-09-23 23:06:19.000000000 -0400
>>> @@ -2281,6 +2281,8 @@ terminal type to a different value."
>>> (defface region
>>> '((((class color) (min-colors 88) (background dark))
>>> :background "blue3")
>>> +    (((class color) (min-colors 88) (background light) (type ns))
>>> +     :background "ns_selection_color")
>>> (((class color) (min-colors 88) (background light))
>>> :background "lightgoldenrod2")
>>> (((class color) (min-colors 16) (background dark))
>> 
>> Could you add a comment explaining why you put (background light) in
>> the specs?  I guess it's because the ns_selection_color is (almost)
>> always defined with the assumption that it will be used on text
>> displayed on a light background., right?

> Something like:

> ;; Region face: under NS, use the system-defined selection color
> ;; (optimized for the system-fixed white background of other apps),
> ;; if background is light.

Looks good, please install it,


        Stefan

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Erik Charlebois]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org  
mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

term/ns-win.el line 1068 sets the face background for 'region to
"ns_selection_color", which is defaulted to lightgoldenrod2 on Macs
and looks rather harsh on dark backgrounds. My problem is that
ns-win.el is eval'd after your .emacs/init.el and will override
any color choices you made for 'region. I'm working around it by
setting the 'region background in a window-setup-hook (which is
after frame-notice-user-settings in startup.el).

It seems like this is a mistake and the 'region face background
should not be set in ns-win.el. It's unintuitive that one specific  
face setting
isn't honoured in your init.el.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/Users/erikc/Documents/emacs/nextstep/Emacs.app/Contents/Resources/etc/ 
DEBUG for instructions.


In GNU Emacs 23.1.50.3 (i386-apple-darwin10.0.0, NS apple- 
appkit-1038.00)
of 2009-09-08 on ermac.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns''

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: nil
   value of $XMODIFIERS: nil
   locale-coding-system: nil
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   display-time-mode: t
   show-paren-mode: t
   global-whitespace-mode: t
   savehist-mode: t
   global-auto-revert-mode: t
   yas/global-mode: t
   yas/minor-mode: t
   shell-dirtrack-mode: t
   mouse-wheel-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x r e p o r t q <backspace> <tab> <return>

Recent messages:
Loading ~/.viper...done
Loading tramp...done
Building list of manual directory expansions...
Building completion list of all manual topics...
Loading /Users/erikc/.emacs.d/anything-c-adaptive-history...done
Setting up CEDET packages...done
Loading /Users/erikc/.emacs.d/haskell-mode-2.4/haskell-site-file.el  
(source)...done
Loading fu...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/Users/erikc/.emacs.d/cedet-1.0pre6/speedbar/speedbar hides /Users/ 
erikc/Documents/emacs/nextstep/Emacs.app/Contents/Resources/lisp/ 
speedbar
/Users/erikc/.emacs.d/cedet-1.0pre6/speedbar/sb-image hides /Users/ 
erikc/Documents/emacs/nextstep/Emacs.app/Contents/Resources/lisp/sb- 
image
/Users/erikc/.emacs.d/cedet-1.0pre6/common/ezimage hides /Users/erikc/ 
Documents/emacs/nextstep/Emacs.app/Contents/Resources/lisp/ezimage
/Users/erikc/.emacs.d/cedet-1.0pre6/speedbar/dframe hides /Users/erikc/ 
Documents/emacs/nextstep/Emacs.app/Contents/Resources/lisp/dframe


Erik Charlebois
erikcharlebois@gmail.com

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Glenn Morris]

reassign 4381 emacs,ns
stop

Erik Charlebois wrote:

> term/ns-win.el line 1068 sets the face background for 'region to
> "ns_selection_color", which is defaulted to lightgoldenrod2 on Macs
> and looks rather harsh on dark backgrounds. My problem is that
> ns-win.el is eval'd after your .emacs/init.el and will override
> any color choices you made for 'region.

ns-win.el is compiled into the Emacs executable, and therefore is
loaded before your .emacs file is processed. So while there may be a
problem here, it probably is something different.

Please post the minimal .emacs that shows the problem, and hopefully a
Mac user can help.

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Erik Charlebois]

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).

Erik Charlebois
erikcharlebois@gmail.com




On 2009-09-09, at 11:27 PM, Glenn Morris wrote:

> reassign 4381 emacs,ns
> stop
>
> Erik Charlebois wrote:
>
>> term/ns-win.el line 1068 sets the face background for 'region to
>> "ns_selection_color", which is defaulted to lightgoldenrod2 on Macs
>> and looks rather harsh on dark backgrounds. My problem is that
>> ns-win.el is eval'd after your .emacs/init.el and will override
>> any color choices you made for 'region.
>
> ns-win.el is compiled into the Emacs executable, and therefore is
> loaded before your .emacs file is processed. So while there may be a
> problem here, it probably is something different.
>
> Please post the minimal .emacs that shows the problem, and hopefully a
> Mac user can help.
>

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Glenn Morris]

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.

bug#4381: 23.1.50; Cocoa Emacs: face background for 'region set in ns-win.el after .emacs

[Erik Charlebois]

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.