[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: Tue, 14 Jan 2014 00:18:10 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/13/2014 11:47 PM, Jan D. wrote:
Your mailer does not quote replies properly, which is distracting.  Can
you fix that?

It looks fine to me.

Daniel Colascione skrev 2014-01-13 22:36:
On 01/13/2014 01:29 PM, Jan Djärv wrote:
13 jan 2014 kl. 19:41 skrev Daniel Colascione <address@hidden>:

On 01/13/2014 08:33 AM, Jan Djärv wrote:
13 jan 2014 kl. 14:13 skrev Daniel Colascione <address@hidden>:
The patch uses the CIE L*A*B colorspace algorithm by default.

Do not change the defaults please. Reinstate the
They are system defined and should be honored.

There are two sane defaults: the 24.3 behavior, where we always use
the system selection foreground and background, and my proposed
behavior, where we use the fontified foreground and automatically
adjust it so that it's legible. The current behavior is worse because
it uses the system selection foreground only sometimes and doesn't
preserve theme hues when possible.

What theme hues? The default theme is not really a theme as
colors are taken from system settings. And this is correct IMHO, any
application that doesn't do so by default (i.e. no user configuration
has been set in the application) is seriously broken.

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. We are *already* not honoring the system-specified
foreground selection color. 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. 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.

Given the use case at hand, we know for a fact that the background is
the region background, so I don't understand why a calculated foreground
is needed.  Just pick one that matches the background.
There might be other use cases where a calculated foreground makes
sense, but my imagination fails me here.

Calculated foreground colors look better: they resemble the font-lock colors on which they're based.

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

FWIW, here Eclipse, XCode and Visual Studio all shows the (equivalent
of) foreground color from font lock face and background from region when
selecting text with the mouse, so it is not as Eamcs is breaking new
ground here.

If you talk about other themes, they can set :distant-foreground to
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.

Again, I really don't see this use case.  Do you have one?

I just mentioned one. See my other email, the one where I laid out the options for Emacs configuration defaults.

We should push policy to user customization when
possible instead of hardcoding policy in the logic of face attributes.

I don't think we do that, users can still customize faces as they see fit.

:distant-foreground has far too narrow a justification to warrant being a face property by itself.

reply via email to

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