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

[Daniel Colascione <dancol@dancol.org>]

On 01/14/2014 08:59 PM, Drew Adams wrote:
>> 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.

So your objection is just to the same face appearing in different colors 
in different contexts? You must loathe XEmacs specifiers, frame-local 
face-remapping tables, and the display-spec portion of face specifications.

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

The foreground of the `region' face isn't being changed. In this 
instance, `region' doesn't have a foreground face set. If the user 
customizes the region face, this entire discussion doesn't apply 
because, at that point, the user can set whatever colors are desired and 
(if necessary) turn off the contrast adjustment.

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

The purpose of using a face with identical foreground and background 
colors would be better served with a text or overlay property. Besides: 
even in 24.3, highlighting a part of the buffer marked with such a face 
makes the hidden text visible.

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

Do you really think users would prefer invisible text?

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

Your entire objection to this feature seems to be driven by some kind of 
Platonic ideal of settings as values that Emacs uses and consistently 
and that never change without explicit user interaction. Preserving 
these properties isn't worth much, especially if it leads to a worse 
user experience.