RE: [PATCH] Re: About the :distant-foreground face attribute

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

> > Region highlighting should never be overridden by font-lock
> > highlighting.
> 
> You can configure Emacs to act that way.

Emacs should act that way by default, as it always has.  Anyone
who wants automatic foreground twiddling for a given face should
ask for that explicitly.  Whether that twiddling is to accommodate
font-locking or for some other reason.

(Likewise, for face filtering, if this feature ends up going
that way in order to generalize the function and give it access
to and effect over all face attributes.)

> > Then choose the `region' background accordingly.  If Emacs cannot
> > do that automatically in the case of some platforms, too bad - let
> > users compensate by setting `region' manually.  They should always
> > be the ultimate judge of what works best for them.
> 
> If we choose a region background that works with traditional font-
> lock colors, that background color cannot come from the system.

Just don't do that.  Certainly not by default.

> If we want the region background color to come from the system,
> we have to have some way of making it contrast with the
> foreground.

What has Emacs done in the past?  Since Emacs can specify the
default background and foreground, it should be trivial for it
to come up with two colors that contrast.  And even two colors
that contrast and are different from the default (e.g. system)
background.

If Emacs on some system (how many are a real problem?) really
cannot find a default `region' background and foreground that
work, then punt and let the user try.  How have we gotten by
for almost 4 decades without this feature?

It's hard to believe that a contrasting pair of default
colors cannot be found.  Just take the font-lock nonsense
out of the equation, and there should be no problem - that's
my guess.

> Emacs won't change any colors users set on the region face.
> If a user sets the region's foreground and background colors,
> Emacs will use those colors for the selection. 

Glad to hear you say that.

And what if the default `region' foreground and background
are exactly what the user wants?  Does s?he have to jump
through a hoop to "set" face attributes to what they already
were, just to say "Hands off!"?  She shouldn't have to.

> We are talking specifically about the case where users do
> *not* specify a foreground color for region.

And what does "not specify" mean?  Does it mean only that
the value has not changed from the standard (default) value?
Or does it mean that users somehow explicitly let you know
that they do not mind if you twiddle their region?

A face being equal to its default setting does not imply
that the user gives Emacs license to change it.

IMO, any such feature should be opt-in, not opt-out.  A
user should not need to explicitly do anything to stop
Emacs from twiddling her region.  She should ask for
twiddling if she wants that.

> Emacs adjusts colors only when a :contrast-function is set
> for some face applying to a particular character and that
> face isn't overridden by one that sets :contrast-function to
> nil.

OK, that sounds a bit better, at least.  So if any face has a
nil :twiddle-me, er sorry, :contrast-function attribute, and
that face is merged with a face that has a non-nil one, the nil
one wins and there is no twiddling.  Is that right?

It is important that no face, including `region', have a
non-nil :contrast-function by default.

> Set foreground and background. Uncheck :constrast-function if
> you want

So it is easy for a user or Lisp code to turn this off.  Good.
Now let's turn it off by default.  It will be just as easy for
a user to turn it on, if s?he wants.

> If a user or package doesn't want automatic contrast
> adjustment, either don't ask for it or explicitly turn it off.

Don't ask for it (i.e., do nothing) sounds good, to keep it off.
Off by default.  Explicitly turn it on if you want it.

What you describe now sounds a bit like what I suggested a week
ago:

>> And that user control should be *per face*.  One should not
>> be obliged to choose either preventing the overriding or
>> allowing it for all faces.  The choice should be a function
>> of the particular face.  Now *that* could be done using a
>> new face attribute, if you want.  (Or a function.)

This is OK as long as any long-existing faces such as `region'
will not have non-nil :contrast-function attributes by default.
Let users who really want their region twiddled opt into that. 

But it still makes life more complicated for Lisp code that
wants to get or set the actual appearance of the face.  Whereas
before code needed only to get or set attribute :foreground,
now it will need to also check for a non-nil :contrast-function
and apply that.

Still, this sounds better than what has been proposed so far.