Re: a review of the merge (Re: Emacs.app merged)

[David De La Harpe Golden <david@harpegolden.net>]

Stefan Monnier wrote:

>> This is so users can enter colors in numeric format, such as ARGBD0FFFFFF.
>> The NS port interprets such formats to allow alpha  specification.
> 
> Can't similar "uncompletable colors" be specified in X11 (with format
> "#RRGGBB" or somesuch)? 

Yes, but  because XParseColor() itself supports #RRGGBB syntax (it's
actually "discouraged", the "recommended" syntax is
"rgb:RR/GG/BB", which also works in x11 emacs, because emacs just calls
XParseColor(), see XParseColor man page)

But while X11 IIUC now supports argb visuals*, XParseColor() does not
support alpha component specification.  This might just be an oversight
by X.org people, or it might be because alpha is just not allowed for in
the existing XColor struct (I'm unclear on whether that struct could
be safely extended by the xlib maintainers).

* so emacs on modern X11 should also be able to do useful (well, mostly
eye-candy) things with alpha values, far finer-grained than
just specifying the overall window transparency for a compositing
manager to pick up (as a recent patch did), so it would certainly be
useful to have support for alpha in emacs color specs for X11 too, but
there'd need to be quite a lot of changes to the rendering path for
maximum coolness (e.g. handwavily, face realisation or thereabouts doing
alpha-compositing rather than mere overriding of color properties so
that region highlighting could be a pretty tinted overlay rather than
just obliterating some parts of existing highlighting it's overlaying.)

> Maybe your change should be applied to
> more platforms?
>

Not sure I like "ARGB11223344" syntax in particular, never seen it
anywhere before, though I guess it doesn't matter much if it's
emacs-internal.  Might be worth asking someone X.org-developer-y what
the X11 syntax should be and whether XParseColor() could/should be
extended to support it.  I'd guess they'd favour  argb:AA/RR/GG/BB
(note that XParseColor already supports
#RRRRGGGGBBBB so #AAARRRGGGBBB is a nonrunner due to ambiguity)