[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 19:52:08 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
On 01/14/2014 07:07 PM, Drew Adams wrote:
I honestly don't understand what you're talking about...
If a user hasn't customized an option and has relied on the
default, we can modify the default values when we update Emacs.
Yes, yes. Emacs Dev can change the default value. No one says
otherwise. What the code being added now does is more than that.
It changes the appearance of the face on the fly - the current
state, not the default value.
And the rationale you gave for dynamically changing the face
appearance was that the user had not customized the face away
from the default spec, so she must not care. That does not
follow.
You're contradicting yourself. You acknowledge that changing defaults is
legitimate. Then you say that a user's failure to customize a face does
not give us license to change the way that face looks by default when we
update Emacs. 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?
Let's talk about the case where users have customized *something*.
The default value for option `foo' is 42. The user does not
change that. That fact alone does not let you presume that
the user does not mind if you change the value of `foo' on
the fly in some contexts to 3000.
A better analogy is this: Emacs comes with a foo parameter, and a user
has customized it to 42. We ship Emacs with a new parameter,
automatically-choose-foo, and default this parameter to t. Under certain
conditions, when 42 is useless and when automatically-choose-foo is t,
we use 50 instead of the user's configured 42. I think we agree that
this kind of automatic-option-overriding behavior is confusing and that
we should have a very good reason before adopting it, weighing the
benefit of automatically-choose-foo against user surprise.
In the particular case of face color, we have a good enough reason.
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 and she runs Emacs on a system where the GTK selection
background color is also HelloKittyPink, then under my proposed scheme,
we'll render function names that appear in the selection using a
slightly different shade of pink or red. If our user is unhappy with
this rendering, she can either change font-lock-function-name-face's
foreground or change the selection background either by changing the
system default background or by changing the region face in Emacs. 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. In the meantime, though, isn't it better for text to be
legible than not?
You would seem to prefer that our user's function names just disappear
when selected and justify this preference with references to data model
purity. Users don't care about purity.
+--------+--------------------+------------------+
| | Good contrast | Bad Contrast |
+--------+--------------------+------------------+
| Auto | Exact color | Color changed |
| Adjust | Happy | Maybe happy? |
+--------+--------------------+------------------+
| Static | Exact color | Text invisible |
| | Happy | Unhappy |
+--------+--------------------+------------------+
Note that we're doing this adjustment only for region. rainbow-mode
performs a similar adjustment, using a different mechanism, for very
similar reasons.
- Re: [PATCH] Re: About the :distant-foreground face attribute, (continued)
- 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/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 <=
- 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
- Re: [PATCH] Re: About the :distant-foreground face attribute, Yuri Khan, 2014/01/14
- Re: [PATCH] Re: About the :distant-foreground face attribute, Jan D., 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, Jan D., 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/13