RE: About the :distant-foreground face attribute

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

> Instead, here's a compromise proposal:
> 
> - Allow :foreground to take the value of (fallback COLOR) or
>   something like that, which would be equivalent to setting
>   :foreground to unspecified and :distant-foreground to COLOR.

I think you are saying to set the face's foreground attribute to
whatever the dwim thingie calculates, which is what I suggested too.
Is that what you mean?

>   (We still need a replacement term for "distant foreground".  As
>   mentioned before, this term sounds nonsensical.)

Yes, if a term is needed at all.  IIUC, there would be no new face
attribute, at least.  The ordinary foreground attribute would be
given whatever clever value is deemed more appropriate, right?

So if a new term is needed for this clever color, then that would
be only for, say, a function name and its doc, not for a new face
attribute - right?

> - In order to avoid incompatibilities, set the :foreground of the
>   `region' face to "*_selection_fg_color".

I don't know what the latter is.  Not that I necessarily need to.
I've already expressed my concerns, and am hoping that they are
taken into account in some way.  I have confidence that you, at
least, understand what my concerns are and will think about them.

>   In other words, avoid using the above feature in the `region'
>   face, at least for Emacs 24.4.

I guess you are saying that the region foreground will not be
adapted automatically to compensate for an unfortunate region
background default choice.  For Emacs 24.4, at least.  Is that
right?

>   The rationale is that (i) we can live with having a fixed
>   foreground color for the `region' face, since that was the
>   case in Emacs 24.3 on GTK anyway.

Can't we live with that as a continuing feature?  That sounds
like TRT, to me.

Let's not forget that the user can define the `region' face
any way s?he wants.  It is not only the foreground that can
"conflict", and it is not only the background that might be
defined.

Similarly, font-lock highlighting can use faces with backgrounds
defined, as well as foregrounds.  Would this clever feature
do the same thing for letting font-lock backgrounds show through
as it aims to do for letting font-lock foregrounds show through?
If not, why not?

There is nothing inherently asymmetrical between foreground and
background, for either face `region' or font-locking.

>   And (ii) not using this feature immediately gives
>   third-party packages a "transition period" to adapt to its
>   presence,

Which means what?

>   without immediately failing by encountering it in a standard
>   face.

What is it that will eventually be encountered in a face,
standard or otherwise?  Are back to an additional face attribute?
Sorry, but I don't understand the proposal.  What is it, in
concrete terms (user terms, Lisp terms)?  What will 3rd-party
code need to know?  What adaptation is needed, in general terms
at least?

> If there are no objections, I can implement this.

I replied so that you know that I don't yet understand what is
being proposed.  I understand that you had problems with this
new feature, as implemented (you filed the bug report).  So I
suppose that you will DTRT.  Still, I would like to understand
what the change will be, if possible.