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

[Daniel Colascione <dancol@dancol.org>]

On 01/14/2014 04:31 PM, Drew Adams wrote:
>>>> If a user never expressed a preference with respect to foreground
>>>> and background colors, there's no contract to violate.
>>>
>>> And how does she express that preference, if it happens to
>>> coincide with the default colors?
>>
>> See above.
>
> So she has to opt out.  She has to realize that she really wants
> the default color attribute values, which she never really sees
> because the automatic tweaking is on by default.

She sees the default attributes --- system selection background, 
font-lock foreground --- almost all the time. Can you give me a concrete 
example of a situation in which this scheme might be problematic?

> And then she
> has to explicitly opt out, to get those colors she has finally
> realized she wants.

We're talking about a default Emacs configuration. Users want legible 
text, and they want Emacs to look like their other applications. We're 
obliging them.

> Just turn it off by default.  For those few platforms that are
> ill-designed enough to present a problem, she will figure out
> whether she wants to remedy that problem by opting into the
> automatic twiddling.  If there really is a visible problem on
> her platform then she will see it and will be able to make an
> informed choice.  Call out this clever compensation in the doc.

Whether we have a contrast problem has absolutely nothing to do with how 
well the system is designed. The variable here is the default selection 
background. Or are you claiming that any system that provides a 
selection background color that conflicts with an Emacs font-lock face 
is badly designed? That's a pretty Emacs-centric view of the world.

I strongly disagree that we should show users illegible text and tell 
them how to correct the problem in the documentation. Users don't change 
defaults when evaluating a product. Emacs should work by default. Users 
should have to opt into breaking their editing environment.

>>> What you are saying is like saying that you think you have a
>>> license to change the value of option `default-frame-alist'
>>> automatically, if the current value is nil, because that's also
>>> the default value.
>>
>> Well, yes, we do have such a license. By this logic, we can't change
>> any default ever.
>
> Did you notice "automatically" and "current value" in that sentence?
> I'm not talking about the license of Emacs Dev to redefine the
> _default_ value.  I'm talking about license to change the _current_
> value of an option, on the fly, automatically, behind the user's
> back... - just because the current value happens to coincide with
> the default value (`nil' in this case).
>
> A user's not customizing an option away from the default value is
> not implicit permission for Emacs to twiddle the current value to
> something different.

I honestly don't understand what you're talking about. Perhaps you can 
rephrase it? If a user has customized an option, we don't touch it. If a 
user hasn't customized an option and has relied on the default, we can 
modify the default values when we update Emacs. All customization 
variables work this way. Faces are not special. Users with custom themes 
won't see a difference.

`nil' isn't a foreground color. It's the absence of a foreground color. 
If a user has customized region and set the region foreground color to 
nil, she's explicitly asked Emacs to combine the region foreground with 
whatever other face happens to be in the buffer. We're just performing 
this combination in a way that yields visible text. Nobody has ever 
deliberately told Emacs to make text illegible when highlighting the 
selection.

You're going on about some kind of intellectual purity and ignoring the 
reality of what users will actually see.