emacs-devel
[Top][All Lists]
Advanced

[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 21:12:44 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/14/2014 08:59 PM, Drew Adams wrote:
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?

It's not about the default.  It's about a user not having
changed the value from the default being taken as an assumption
that the user does not care whether you change the face
appearance later, on the fly, in some contexts.

So your objection is just to the same face appearing in different colors in different contexts? You must loathe XEmacs specifiers, frame-local face-remapping tables, and the display-spec portion of face specifications.

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

No, this is about the `region' face.  My analogy was wrt the
thing that you will be twiddling, which is the `region'
foreground.  Customization of other faces or options is not
the question.

The foreground of the `region' face isn't being changed. In this instance, `region' doesn't have a foreground face set. If the user customizes the region face, this entire discussion doesn't apply because, at that point, the user can set whatever colors are desired and (if necessary) turn off the contrast adjustment.

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.

Such that the _combination becomes legible_?  That is now the
price of your respecting a user customization of `region'?
It is not enough that she customizes `region', to have you
leave her region highlighting alone?  That customization now has
to result in a combination that you find legible?

In that case, there is no respect of the user's customization.
That is respect only when respect doesn't matter and has no cost
or effect.

Previously you said categorically that if the user customizes
`region' then you will attempt no adjustment.  Now you say that
if she does that, AND if no adjustment is needed, then you will
perform no adjustment!

You are kind enough to say that if you find that no adjustment
is needed you will offer a dispensation from adjusting.  When
your adjustment would amount to a no-op you will kindly forego it.
Gee, thanks.

In the meantime, though, isn't it better for text to be
legible than not?

Isn't it better to let the user decide what appearance she
wants, whether you think it is appropriate or not?

People have several times mentioned the fact that certain
libraries intentionally specify foreground and background
to be the same color for some faces.  This change flies in the
face of that use case, even if you limit it to `region' for now
(you said you would prefer to generalize it, but would limit it
for now).

The purpose of using a face with identical foreground and background colors would be better served with a text or overlay property. Besides: even in 24.3, highlighting a part of the buffer marked with such a face makes the hidden text visible.

You would seem to prefer that our user's function names
just disappear when selected

It's not about what colors I prefer for the face.  It's about
what the user prefers.

Do you really think users would prefer invisible text?

Users don't care about purity.

Whatever that means.  No idea what purity you think I'm
requesting.

But I shudder when I see blanket declarations that users
don't care about this or that, even something so meaninglessly
abstract as "purity".

Your entire objection to this feature seems to be driven by some kind of Platonic ideal of settings as values that Emacs uses and consistently and that never change without explicit user interaction. Preserving these properties isn't worth much, especially if it leads to a worse user experience.



reply via email to

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