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

[Daniel Colascione]

On 01/13/2014 03:01 PM, Drew Adams wrote:
> > Yes, but font-lock colors are specified with explicit colors (even
> > in the default "theme"), and we want to preserve these even in the
> > presence of a selection.
>
> I, for one, do not want that.  I want region highlighting to
> correctly show which characters have been selected - each character.
> Region highlighting should never be overridden by font-lock
> highlighting.  UI-101: Intro to User Interfaces.

Okay, good for you. You can configure Emacs to act that way.

> > At the same time, we want to make sure that highlighted text is
> > legible against a background of whatever the system selection color
> > happens to be.
>
> 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.

If we choose a region background that works with traditional font-lock 
colors, that background color cannot come from the system. If we want 
the region background color to come from the system, we have to have 
some way of making it contrast with the foreground. You cannot 
simultaneously "choose the `region' background accordingly" and respect 
system preferences.

> > The best way to do that is to automatically shift the foreground
> > colors in value, but not hue, so that they remain legible while
> > being recognizably the same color.
>
> No.  The best way to do that is to let users do it - let their
> preferences rule.  Users do not need Emacs changing whatever values
> they set for the `region' face.

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. This is not a difficult concept to grasp. We 
are talking specifically about the case where users do *not* specify a 
foreground color for region. For better or worse, it seems that Emacs 
will be shipping this way, so we should make this configuration work as 
well as we can.

> And if you say that your new feature does not override user preference
> for `region', how can you determine that?  You cannot just compare the
> current value to the standard value, since the standard value might in
> fact be just what the user wants.  Who are we to say we know better
> than the user?

I have no idea what you are talking about. The current value of what? 
The standard value of what?

> > I think the results are actually pretty good.
>
> That does not sound like a ringing endorsement.  Does that mean that
> only 25% of user preferences are ignored?  10%?

I said I found the results acceptable. Why are you trying to read 
meaning that isn't present into my post?

> > If a particular theme doesn't want to use automatic color adjustment,
> > it can specify its own :contrast-function and do whatever it wants.
>
> So if it does not specify a :contrast-function, you take that as a
> license to impose a standard one, instead of as a preference to not
> perform any :contrast-function twiddling at all?

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.

> > I would also support a scheme where, by default, 'region' sets
> > foreground *and* background colors to the system selection colors
> > and other faces don't show through. But we didn't decide to go in that
> > direction.
>
> How about supporting the time-worn "scheme" whereby users and Lisp
> code can specify clearly what the region highlighting foreground and
> background are, literally, with nothing hidden behind their backs
> playing tricks on them?  IOW, treat `region' like other faces, and
> treat its foreground and background equally.

M-x customize-face RET region RET

Set foreground and background. Uncheck :constrast-function if you want, 
although if selecting good colors is as good as you claim, the contrast 
function will never go into effect anyway.

> > > If you talk about other themes, they can set :distant-foreground
> > > to a real color of their choosing and not rely on some automatically
> > > generated one which most probably don't fit the theme anyway.
> > > Automatically generated colors are a crutch which should be avoided
> > > if possible, certainly not recommended.
> >
> > There's no way that themes can take into account all the possible
> > colors users and packages might use. Automatic contrast adjustment
> > can do that.
>
> Bzzzzzt!  No, but thanks for playing.

You're really elevating the level of discourse around here, aren't you?

> Automatic contrast adjustment
> can never respect all user (or package) `region' specs, precisely
> because it *automatically adjusts* the appearance away from what users
> (or packages) specify.>

Of course users specify it --- it's part of the damn face. It's 
specified *right there*. If a user or package doesn't want automatic 
contrast adjustment, either don't ask for it or explicitly turn it off.

> > If you want the :distant-foreground behavior, it can be accommodated
> > in this patch. This patch also permits other schemes that some users
> > might find more useful. We should push policy to user customization
> > when possible instead of hardcoding policy in the logic of face
> > attributes.
>
> We should leave face specs defined by users and packages well enough
> alone.  Let them decide what they want - and let them get what they
> want, without the "benefit" of behind-the-back twiddling.  Users
> deserve honest transparency, not parlor magic tricks.

Yes, users should be in control. That's precisely what this change 
allows. Can you please try to understand it before haranguing it?