RE: About the :distant-foreground face attribute

[Drew Adams <drew.adams@oracle.com>]

> Count this as an objection. (i) means reopening a fixed bug BTW,
> don't forget that.

On the contrary.  It fixed a non-bug, and introduced a regression.
It forces Lisp code to access and manipulate actual face
foregrounds (what is really shown, not counting effects of other
faces etc.) in a new, kludgy way.

> 1) We are talking about a replacing a feature that has no
> outstanding bugs, and has been in place for about 2 months.

Do you want me to file a bug for this regression?

> 2) The only reason too replace it is some personal feelings about
> "clean design", based on unknown principles, that are not documented
> in any Emacs or GNU document.

Among the reasons to remove this regression are: (a) it breaks
existing Lisp code and complicates future code, (b) it is lousy UI,
going counter to selection in other apps, (c) it is not needed for
anything, (d) it treats foreground differently than background
(asymmetric), and so does not solve the problem it purports to,
since both `region' and font-lock can specify either foreground or
background, or both, (e) it tries to work around a non-Emacs problem
of certain platforms providing poor default selection background
colors.

> 3) The code for this proposal will be messier.  Distant-foreground
> is quite separate in the code, you can easily find any place where
> the source handles to it.  This proposal suggests modifying
> foreground, thus changing a lot of places where foreground are
> handeled.  Not only is this bound to introduce bugs, but the
> feature is not as easily seen in the source.

The introduction of an additional face attribute that is not
independent of attribute foreground, and that affects the
perceived foreground of the face, and so breaks the one-to-one
relation between a face's foreground attribute and the face's
perceived foreground, is an ill-conceived, error-prone hack.

It complicates any Lisp code that tries to deal with the actual
face foreground based on its foreground attribute.  And that's in
the best of cases: future code.  Existing code is simply broken,
if it expects the face's foreground attribute and appearance to
correspond.

> And all this during a feature freeze?

This new "feature" should never have been approved.  It is simply
an unfortunate regression.  It should be pulled out pronto.

> It makes feature freeze kind of pointless if any feature can be
> replaced willy nilly based on a persons design feelings.

Feature freeze is the time to test the product, including changes
that have been made.  This change does not pass the smell test,
let alone any usability tests for Lisp code.  It will even
confuse users in UI terms, when they try to check the foreground
at some position.

> But this is Stefans call.