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

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

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

No.  You added "by default".  You keep doing that.  And I keep
explaining that it is the _on-the-fly appearance change_ that
does not follow from a user not customizing the default.

> when we update Emacs. 

And you keep repeating that, though I have made it clear that
this is not about your having the right to change the default
value when you update Emacs.  I couldn't be clearer about that.

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

It's not about the default.  It's about a user not having
changed the value from the default being taken as an assumption
that the user does not care whether you change the face
appearance later, on the fly, in some contexts.

Not customizing away from the default value says nothing about
the user not caring about the appearance.

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

Note: "on the fly in some contexts".  Nothing about changing
the default value.

> A better analogy is this: Emacs comes with a foo parameter,
> and a user has customized it to 42. 

No, you have not understood my point, so you are coming up with
stuff that is off the mark.

You have already reassured us all that if the user customizes
face `region' then you will not override that user preference
with on-the-fly foreground twiddling.  So no one is talking
about the case where the user customizes, since that case is
apparently not changed - you will continue to respect the user
customization, right?

The analogy was for the case where the user does *not* change
the default value - does not customize the face (the option,
in the analogy).  That lack of customization does not imply
not caring about the value and thus give implicit permission
to change it on the fly when you think that is appropriate.

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

No, this is about the `region' face.  My analogy was wrt the
thing that you will be twiddling, which is the `region'
foreground.  Customization of other faces or options is not
the question.

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

Such that the _combination becomes legible_?  That is now the
price of your respecting a user customization of `region'?
It is not enough that she customizes `region', to have you
leave her region highlighting alone?  That customization now has
to result in a combination that you find legible?

In that case, there is no respect of the user's customization.
That is respect only when respect doesn't matter and has no cost
or effect.

Previously you said categorically that if the user customizes
`region' then you will attempt no adjustment.  Now you say that
if she does that, AND if no adjustment is needed, then you will
perform no adjustment!

You are kind enough to say that if you find that no adjustment
is needed you will offer a dispensation from adjusting.  When
your adjustment would amount to a no-op you will kindly forego it.
Gee, thanks.

> In the meantime, though, isn't it better for text to be
> legible than not?

Isn't it better to let the user decide what appearance she
wants, whether you think it is appropriate or not?

People have several times mentioned the fact that certain
libraries intentionally specify foreground and background
to be the same color for some faces.  This change flies in the
face of that use case, even if you limit it to `region' for now
(you said you would prefer to generalize it, but would limit it
for now).

> You would seem to prefer that our user's function names
> just disappear when selected

It's not about what colors I prefer for the face.  It's about
what the user prefers.

> Users don't care about purity.

Whatever that means.  No idea what purity you think I'm
requesting.

But I shudder when I see blanket declarations that users
don't care about this or that, even something so meaninglessly
abstract as "purity".