[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 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

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.

reply via email to

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