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

From: Steve Purcell <[email-masked]>
Date: Fri, 6 May 2011 22:24:36 +0100

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.