[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: [PATCH] Re: About the :distant-foreground face attribute
Date: Mon, 13 Jan 2014 18:34:38 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

It sounds like we're in broad agreement on the mechanism. Now let's talk about default policy.

On 01/13/2014 05:32 PM, Drew Adams wrote:
Region highlighting should never be overridden by font-lock

You can configure Emacs to act that way.

Emacs should act that way by default, as it always has.  Anyone
who wants automatic foreground twiddling for a given face should
ask for that explicitly.  Whether that twiddling is to accommodate
font-locking or for some other reason.

I don't have a strong opinion about the default, although I lean toward the behavior #3 (3b specifically) below since it looks blingy and might help attract new users.

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.

I still don't understand exactly what you're proposing. Here are our options:

1) We can ship Emacs with hard-coded defaults for region's foreground and background colors and ignore system settings. This arrangement will produce legible text, and there's no need to adjust region's colors.

2) We can ship Emacs such that it uses the system selection foreground and background colors for region. This arrangement will also produce legible text, and there's no need to adjust region's colors.

3) We can ship Emacs such that it uses the system selection background color and uses font-lock colors for foreground text. This arrangement will sometimes produce an illegible result because the system background color is chosen independently of font-lock's face colors. We can

3a) do nothing and make users customize either their system selection color, Emacs region face, or font-lock color scheme

3b) Automatically adjust foreground colors when the region face is in effect so that they're legible against the system selection background color. This is the policy my patch makes Emacs use by default and it's the one I prefer.

3c) Switch to the system selection foreground color when the foreground color we would otherwise use would be illegible against the system selection background color. My patch can support this policy, and it's the only policy :distant-foreground supports.

3d) Adjust the region face background color until it's legible against all font-lock faces? I *think* this is what you're proposing, but it doesn't make any sense. If we diverge from the system selection background color, we've already lost the integration benefit and should just use option #1 above.

So to put the discussion in more concrete terms: say I run a stock GTK3 Emacs on a system with a background color exactly equal to "Blue1", which is the color we use for font-lock-function-name-face. I visit xfaces.c, search for "UNSPECIFIEDP", and hit C-a C-SPC C-e. What colors do you propose we use for the text "UNSPECIFIEDP" on that line?

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.

And what if the default `region' foreground and background
are exactly what the user wants?  Does s?he have to jump
through a hoop to "set" face attributes to what they already
were, just to say "Hands off!"?  She shouldn't have to.

If we ship configuration 3b, we won't set a foreground color and we'll use the specified region background color (which will come from the system) and the font-lock supplied foreground unless the foreground would be illegible against the background. In this case, we adjust the foreground color until it's legible.

If a user wants to customize the selection color and uses M-x customize-face RET region RET, she'll be able to set foreground and background independently. If she unchecks :contrast-function, we will always use those colors exactly.

If she leaves :contrast-function set, Emacs will always use her specified colors unless, again, the combination would be illegible, and in this case, Emacs will adjust the foreground color until it becomes legible. But why would she select a foreground and background colors combination that is illegible in the first place?

We are talking specifically about the case where users do
*not* specify a foreground color for region.

And what does "not specify" mean?  Does it mean only that
the value has not changed from the standard (default) value?
Or does it mean that users somehow explicitly let you know
that they do not mind if you twiddle their region?

It depends on the configuration we ship.

A face being equal to its default setting does not imply
that the user gives Emacs license to change it.

I disagree. If our user leaves a face at the default setting, she's giving us *explicit license* to use whatever heuristics we think work best.

IMO, any such feature should be opt-in, not opt-out.  A
user should not need to explicitly do anything to stop
Emacs from twiddling her region.  She should ask for
twiddling if she wants that.

I'm in favor of shipping defaults that create a good user experience. If a user never expressed a preference with respect to foreground and background colors, there's no contract to violate.

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

OK, that sounds a bit better, at least.  So if any face has a
nil :twiddle-me, er sorry, :contrast-function attribute, and
that face is merged with a face that has a non-nil one, the nil
one wins and there is no twiddling.  Is that right?

Right now, it depends on the order in which the faces are merged. The last face that specifies a :contrast-function gets to control the contrast behavior. Right now, region is the only face that specifies a contrast-function, and I can't think of another good use case at the moment.

It is important that no face, including `region', have a
non-nil :contrast-function by default.

I disagree. Putting it on :region by default is perfectly fine. Remember that the attribute has no effect unless the result would otherwise be illegible.

And that user control should be *per face*.  One should not
be obliged to choose either preventing the overriding or
allowing it for all faces.  The choice should be a function
of the particular face.  Now *that* could be done using a
new face attribute, if you want.  (Or a function.)

This is OK as long as any long-existing faces such as `region'
will not have non-nil :contrast-function attributes by default.
Let users who really want their region twiddled opt into that.

But it still makes life more complicated for Lisp code that
wants to get or set the actual appearance of the face.  Whereas
before code needed only to get or set attribute :foreground,
now it will need to also check for a non-nil :contrast-function
and apply that.

The C code already has functionality to compute the exact face used to render a particular location in a particular buffer in a particular frame. We could expose this functionality to lisp if there were a good use case. But right now, I don't understand why lisp code would need to know the post-adjustment colors used for display. Can you explain why we'd want to know?

Also, today, any lisp code that wants to mimic the redisplay face combination logic needs to take into account text properties, frame-local variables, overlays, display attributes, and so on. It would be a big job, and I'm not aware of anyone who's done it.

Still, this sounds better than what has been proposed so far.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]