RE: About the :distant-foreground face attribute

[Drew Adams]

> > All new features should be proposed and discussed, before being
> > cast into the product.  That's my humble opinion.
> 
> This one was.  It solved a bug.

The new feature was not proposed on emacs-devel and discussed.
It was dreamt up in passing, in one short bug thread, and discussed
there by only two developers.

> > Why is any approach needed?  What is the (real) problem that needs
> > solving?
> 
> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15668.

So the real problem was to have a reasonable background color for
face `region' by default.  On some platforms a bad color choice
was (and apparently still is) being used as the default.

That problem does not require this particular "fix".  Even that
bug thread shows that this was thought to be a nice-to-have new
feature that could also take care of this bug.  It is not needed,
to fix the bug.

  "It would be nice if one could define a face with a foreground
   color to be used when foreground and background otherwise are
   to[o] similar."

And from that dream onward to this one (still unimplemented,
I hope):

>>> It would be nice if...
>>
>> Sounds like a simple enough extension to defface.
>
> Or maybe every face should do that by default.

IMO, the implementation, and probably the feature itself, is not
TRT.

Note, BTW, that even the OP had to back you off the first
enthusiastic fix, so that he could still customize normally and
theme designers would have a simpler time of it.

> I envisioned that querying the face for the foreground would
> automatically give the "fallback"...

At least that was thought of.  But is that the case for all code
that "queries" a face :foreground or modifies it?  Is all such
code somehow automatically adjusted now so that it always DTRT?
I don't see how that would be the case.

It seems that for one tiny piece of the distributed Emacs code
that dream behavior was implemented.  The problem is all other
code that tries to use the :foreground, which attribute might
not even be respected (unused, because of a DWIM substitution).

Such code thinks that it is getting or changing the foreground
color by dealing with just :foreground.  But it is wrong,
because a clever DWIM feature went behind its back.  To DTRT,
it will now have to jump through extra hoops.