bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa))

[Steve Purcell]

On 6 May 2011, at 20:59, David De La Harpe Golden wrote:

> I still don't know exactly what DigitalColor Meter is doing.


Same here.


> > Nonetheless, I think the browsers are getting it right by doing what
> > users expect,
> 
> Er. I think that's sorta the wrong way round, what's happening is that
> browsers are starting to generate user expectations for other apps -
> like yours. Browsers, again, are flat-out required to use sRGB [5]. Web
> folk of course are a major group of emacs users, so it's IMO worth
> catering to their needs.  But I'm not sure it's sufficient reason to
> switch the default on its own, more of an argument for adding the
> switching capability previously discussed.


+1.


> Though if emacs were to wholeheartedly adopt a standard interpretation
> of intraemacs color strings on all color-management-capable platforms,
> then Apple Generic RGB would obviously be a hopeless basis (though could
> still be provided for with a prefix, say, "AppleGenericRGB:r/g/b").
> 
> Perhaps it could be semiseriously argued that emacs, as it is capable
> of acting as a quite usable web browser via w3 or emacs-w3m, should use
> sRGB and the web named-colors values.


<chuckle>

I certainly think there's an opportunity to review the status quo on all 
supported window systems, and to figure out if there's a desire/basis for 
standardization on something like sRGB.

I'm going to bow out, because I don't think I have any further insights to 
offer.



> [4] TextMate is even the first text editor in quite a while to do anything 
> particularly interesting from the emacs community perspective - right now, 
> you have to add the sorta-kludgey "mumamo" found in the "nxhtml" suite for 
> emacs to catch up with it in some areas.


Agreed - I use the somewhat-antiquated MMM mode myself, which has less baggage 
than mumamo, but is decidedly creaky.