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

[Daniel Colascione <dancol@dancol.org>]

On 01/14/2014 07:07 PM, Drew Adams wrote:
>> I honestly don't understand what you're talking about...
>> If a user hasn't customized an option and has relied on the
>> default, we can modify the default values when we update Emacs.
>
> Yes, yes.  Emacs Dev can change the default value.  No one says
> otherwise.  What the code being added now does is more than that.
> It changes the appearance of the face on the fly - the current
> state, not the default value.
>
> And the rationale you gave for dynamically changing the face
> appearance was that the user had not customized the face away
> from the default spec, so she must not care.  That does not
> follow.

You're contradicting yourself. You acknowledge that changing defaults is 
legitimate. Then you say that a user's failure to customize a face does 
not give us license to change the way that face looks by default when we 
update Emacs. That's a bizarre claim. Are we supposed to never update 
faces, or are we supposed to telepathically know whether the user is 
happy with the previous version's default?

Let's talk about the case where users have customized *something*.

> The default value for option `foo' is 42.  The user does not
> change that.  That fact alone does not let you presume that
> the user does not mind if you change the value of `foo' on
> the fly in some contexts to 3000.

A better analogy is this: Emacs comes with a foo parameter, and a user 
has customized it to 42. We ship Emacs with a new parameter, 
automatically-choose-foo, and default this parameter to t. Under certain 
conditions, when 42 is useless and when automatically-choose-foo is t, 
we use 50 instead of the user's configured 42. I think we agree that 
this kind of automatic-option-overriding behavior is confusing and that 
we should have a very good reason before adopting it, weighing the 
benefit of automatically-choose-foo against user surprise.

In the particular case of face color, we have a good enough reason.

> Yes, the analogy is not exact. You are not changing the
> `foreground' attribute itself.  You are changing the face's
> foreground appearance.  The `foreground' attribute says nil
> or "LightBlue" or whatever the default defface specifies,
> but on the fly the apparent foreground sometimes ends up
> being "HelloKittyPink" (even though the attribute value has
> not changed).

Yes, if a user has customized font-lock-function-name-face to 
HelloKittyPink and she runs Emacs on a system where the GTK selection 
background color is also HelloKittyPink, then under my proposed scheme, 
we'll render function names that appear in the selection using a 
slightly different shade of pink or red. If our user is unhappy with 
this rendering, she can either change font-lock-function-name-face's 
foreground or change the selection background either by changing the 
system default background or by changing the region face in Emacs. Once 
she changes either such that the font-lock-function-name-face-on-region 
combination becomes legible, we use the specified colors without any 
adjustment. In the meantime, though, isn't it better for text to be 
legible than not?

You would seem to prefer that our user's function names just disappear 
when selected and justify this preference with references to data model 
purity. Users don't care about purity.

+--------+--------------------+------------------+
|        | Good contrast      | Bad Contrast     |
+--------+--------------------+------------------+
| Auto   | Exact color        | Color changed    |
| Adjust | Happy              | Maybe happy?     |
+--------+--------------------+------------------+
| Static | Exact color        | Text invisible   |
|        | Happy              | Unhappy          |
+--------+--------------------+------------------+

Note that we're doing this adjustment only for region. rainbow-mode 
performs a similar adjustment, using a different mechanism, for very 
similar reasons.