2

If .emacs contains the following two lines

(set-face-foreground 'modeline "#000000") 
(set-face-background 'modeline "#00FFFF")

then Emacs 22 correctly uses color #00FFFF (cyan), but Emacs 23 uses a different shade of blue (#90FBFE).

What is happening?

An image will illustrate the problem, but because I'm a new user here, stackoverflow will not let me save an image. In the meantime, here is the image hosted elsewhere: http://postimage.org/image/1j2ya1ddw/

Drew
  • 29,895
  • 7
  • 74
  • 104
Sam
  • 563
  • 5
  • 15
  • Can you post the screenshots of the discrepancies that you observe? – vpit3833 Apr 10 '11 at 07:41
  • I'm not sure if this would address your problem, but the approved way these days to set the mode line face these days is `M-x customize-face mode-line`. – dfan Apr 10 '11 at 15:07
  • Using customization produces identical results. "Red" is not red; "cyan" is not cyan; etc. – Sam Apr 10 '11 at 15:28
  • I see the discrepancies. http://html-color-codes.com/ is the top hit I get for color hex codes on Google. Are you referring to some standard color representations? I am no expert in colors. On my Emacs23 (on Debian Linux), "#00FFFF" and "#90FBFE" are different colors. I don't have emacs22 handy though to see the differences for myself. It could have something to do with standards of color representation. – vpit3833 Apr 10 '11 at 23:15
  • Besides, `(color-values "cyan")` gives `(0 65535 65535)` in my emacs23 on Debian Linux. That is, it thinks "#00FFFF" is cyan, and, "#90FBFE" is not. – vpit3833 Apr 10 '11 at 23:19

2 Answers2

1

Version 23 on OS X uses the new Cocoa front-end, and the colors are rendered incorrectly both in that version and in the current dev Emacs. I opened a bug for this last week, having been working on a color theme using precisely-selected colors, and the developers appear to be in the process of accepting the bug's validity.

sanityinc
  • 15,002
  • 2
  • 49
  • 43
  • This is it. Emacs 23 appears to be applying some function from the requested to the provided colors. The result is to somewhat wash-out the colors. We can put this issue to rest here, and if the interface at stackoverflow lets us, append a note later indicating the solution. – Sam Apr 11 '11 at 12:48
  • @user700648 Yep. Just mark this as the correct answer, and either of us can leave a comment later when the bug has been fixed. – sanityinc Apr 11 '11 at 13:16
  • If you want to fix it now I had some luck with a small change and a recompile of Emacs. See [this comment on the bug](http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8402#14). – erik Apr 11 '11 at 14:48
  • @erik Thanks for confirming that the patch works. I'm hoping it will get committed to the official emacs tree. – sanityinc Apr 11 '11 at 16:21
0

For me this two lines do their job, but if I set an alpha parameter of a selected frame then colors change similar. I've looked at the emacs 22.3 manual and found nothing about the alpha parameter. But if you look at the 23.3 manual you could find this phrase in the `alpha' parameter section:

It can also have a `nil' value, which tells Emacs not to set the frame opacity (leaving it to the window manager).

Maybe your window manager changes the colors of a frame? If it so this line of code can help you:

 (set-frame-parameter (selected-frame) 'alpha 100)
m039
  • 1,329
  • 13
  • 11
  • Nice suggestion, but that doesn't solve the problem. See http://postimage.org/image/2hnpry8v8 for the colors after setting alpha to 100. – Sam Apr 11 '11 at 04:02
  • @user700648 In the screenshot that is appended there is "#FFOOFFFF" value maybe you want to use "#00FFFF". I've seen the usage of values similar to "#FF00FFFFFF" [here] (http://www.emacswiki.org/emacs/TransparentEmacs), but they are not used in the 23 emacs. In the 22 emacs manual there is no such parameter as alpha parameter for a frame, so you don't need to specify it in the 22 emacs. – m039 Apr 11 '11 at 09:58
  • "#FFOOFFFF" was one of the variations I tried. The colors are also wrong when using "#OOFFFF". – Sam Apr 11 '11 at 13:00