[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
highlighting.
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
nil.
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.
Thanks.
- Re: [PATCH] Re: About the :distant-foreground face attribute, (continued)
- Re: [PATCH] Re: About the :distant-foreground face attribute, Jan Djärv, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Jan Djärv, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Jan Djärv, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/13
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/13
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/13
- Re: [PATCH] Re: About the :distant-foreground face attribute, Stefan Monnier, 2014/01/13
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/14
- Re: [PATCH] Re: About the :distant-foreground face attribute,
Daniel Colascione <=
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/14
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/14
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/14
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/14
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/14
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/14
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/15
- Re: [PATCH] Re: About the :distant-foreground face attribute, Daniel Colascione, 2014/01/15
- RE: [PATCH] Re: About the :distant-foreground face attribute, Drew Adams, 2014/01/15
- Re: [PATCH] Re: About the :distant-foreground face attribute, Stefan Monnier, 2014/01/15