RE: About the :distant-foreground face attribute

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

> >> Please don't.  That too would break code that expects :foreground
> >> to be as it is now.
> >
> > Why do you assume that the previous form will not be accepted?  Of
> > course, it will be.
> 
> What Drew is worrying about, I think, is that third-party code, or
> old versions of Emacs, will barf when they come across the new
> :foreground form in user customizations or themes.

Yes, that is exactly what motivated my reply there.

But that is not the main point I argue.  The main point is that this
feature is misguided.  A selection (e.g. Emacs region) highlight
_should_ override other highlighting.  You need to be able to see
clearly which text has been selected, each and every character.

IIUC, this enhancement request came about because some platforms
impose default region backgrounds that are inappropriate, being the
same as or too close to the default foreground.

My answer to that would be: (a) not Emacs's problem (a la Eli) -
lobby the platform, (b) too bad, (c) let the user customize face
`region' to get a better background.

Users can define both the foreground and background of face `region'.
It should be trivial to do that so there is no conflict and all text
selected is easily readable.  End of story, no?

Why is it "necessary" that font lock highlighting show through the
text selection (region)?  Answer: it's not.  It's not only not
necessary (YAGNI), but it is wrong (misguided).  The selection
_should_ take precedence.

> I don't know whether this would be a major problem in practice.
> Personally, I agree with David Engster that
> 
>   If you really really want font-lock on a marked region, then you
>   will have to choose a region background which will play well with
>   your color theme.  Introducing a new face attribute for such a small
>   annoyance looks like overkill to me.
> 
> But IF people feel really strongly about having this feature, doing
> it by adding a new :foreground type seems like the least bad option,
> from a code cleanliness perspective.

It is backward incompatible.  It solves a non-problem.  It imposes
unconventional, unexpected, confusing UI interaction that can reduce
a user's ability to tell just which characters have been selected.
Not a bug.