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

[Daniel Colascione <dancol@dancol.org>]

It sounds like we're in broad agreement on the mechanism. Now let's talk 
about default policy.

On 01/13/2014 05:32 PM, Drew Adams wrote:
>>> 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.

I don't have a strong opinion about the default, although I lean toward 
the behavior #3 (3b specifically) below since it looks blingy and might 
help attract new users.

>>> 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.

I still don't understand exactly what you're proposing. Here are our 
options:

1) We can ship Emacs with hard-coded defaults for region's foreground 
and background colors and ignore system settings. This arrangement will 
produce legible text, and there's no need to adjust region's colors.

2) We can ship Emacs such that it uses the system selection foreground 
and background colors for region. This arrangement will also produce 
legible text, and there's no need to adjust region's colors.

3) We can ship Emacs such that it uses the system selection background 
color and uses font-lock colors for foreground text. This arrangement 
will sometimes produce an illegible result because the system background 
color is chosen independently of font-lock's face colors. We can

   3a) do nothing and make users customize either their system selection 
color, Emacs region face, or font-lock color scheme

   3b) Automatically adjust foreground colors when the region face is in 
effect so that they're legible against the system selection background 
color. This is the policy my patch makes Emacs use by default and it's 
the one I prefer.

   3c) Switch to the system selection foreground color when the 
foreground color we would otherwise use would be illegible against the 
system selection background color. My patch can support this policy, and 
it's the only policy :distant-foreground supports.

   3d) Adjust the region face background color until it's legible 
against all font-lock faces? I *think* this is what you're proposing, 
but it doesn't make any sense. If we diverge from the system selection 
background color, we've already lost the integration benefit and should 
just use option #1 above.

So to put the discussion in more concrete terms: say I run a stock GTK3 
Emacs on a system with a background color exactly equal to "Blue1", 
which is the color we use for font-lock-function-name-face. I visit 
xfaces.c, search for "UNSPECIFIEDP", and hit C-a C-SPC C-e. What colors 
do you propose we use for the text "UNSPECIFIEDP" on that line?

>> 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.
>
> 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.

If we ship configuration 3b, we won't set a foreground color and we'll 
use the specified region background color (which will come from the 
system) and the font-lock supplied foreground unless the foreground 
would be illegible against the background. In this case, we adjust the 
foreground color until it's legible.

If a user wants to customize the selection color and uses M-x 
customize-face RET region RET, she'll be able to set foreground and 
background independently. If she unchecks :contrast-function, we will 
always use those colors exactly.

If she leaves :contrast-function set, Emacs will always use her 
specified colors unless, again, the combination would be illegible, and 
in this case, Emacs will adjust the foreground color until it becomes 
legible. But why would she select a foreground and background colors 
combination that is illegible in the first place?

>> 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?

It depends on the configuration we ship.

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

I disagree. If our user leaves a face at the default setting, she's 
giving us *explicit license* to use whatever heuristics we think work best.

> 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.

I'm in favor of shipping defaults that create a good user experience. If 
a user never expressed a preference with respect to foreground and 
background colors, there's no contract to violate.

>> 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?

Right now, it depends on the order in which the faces are merged. The 
last face that specifies a :contrast-function gets to control the 
contrast behavior. Right now, region is the only face that specifies a 
contrast-function, and I can't think of another good use case at the moment.

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

I disagree. Putting it on :region by default is perfectly fine. Remember 
that the attribute has no effect unless the result would otherwise be 
illegible.

>>> 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.

The C code already has functionality to compute the exact face used to 
render a particular location in a particular buffer in a particular 
frame. We could expose this functionality to lisp if there were a good 
use case. But right now, I don't understand why lisp code would need to 
know the post-adjustment colors used for display. Can you explain why 
we'd want to know?

Also, today, any lisp code that wants to mimic the redisplay face 
combination logic needs to take into account text properties, 
frame-local variables, overlays, display attributes, and so on. It would 
be a big job, and I'm not aware of anyone who's done it.

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

Thanks.