About the :distant-foreground face attribute

classic Classic list List threaded Threaded
130 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

About the :distant-foreground face attribute

Chong Yidong
What is the purpose of this face attribute, newly introduced for 24.4?
It seems to be unused in Emacs itself.  Is there a concrete example of
this being needed in external packages or themes?

First of all, the name :distant-foreground is not intuitive.  What does
"distant" mean in this context?

Also, this feature has one ugly consequence.  Previously, the `default'
face must have all its face attributes specified, but now its
:distant-foreground face is unspecified.

Besides that, the implementation seems rather incomplete.  The Customize
interface, `modify-face', `face-spec-reset-face', and other parts of
Emacs haven't been updated for the existence of this face attribute.
It's unclear what functions like `face-foreground' should now do if
there's a :distant-foreground.

This all sounds like an invitation for more bugs.  In my opinion, this
feature is a bad idea.

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Jan D.-2
Hello.

7 jan 2014 kl. 13:55 skrev Chong Yidong <[hidden email]>:

> What is the purpose of this face attribute, newly introduced for 24.4?

Too lazy to read documentation?

"`:distant-foreground'
     Alternative foreground color, a string.  This is like `:foreground'
     but the color is only used as a foreground when the background
     color is near to the foreground that would have been used.  This
     is useful for example when marking text (i.e. the region face).
     If the text has a foreground that is visible with the region face,
     that foreground is used.  If the foreground is near the region
     face background, `:distant-foreground' is used instead so the text
     is readable.
"

> It seems to be unused in Emacs itself.  Is there a concrete example of
> this being needed in external packages or themes?

Too lazy too read the code?

faces.el:

(defface region
  '((((class color) (min-colors 88) (background dark))
     :background "blue3")
    (((class color) (min-colors 88) (background light) (type gtk))
     :distant-foreground "gtk_selection_fg_color"
     :background "gtk_selection_bg_color")
    (((class color) (min-colors 88) (background light) (type ns))
     :distant-foreground "ns_selection_fg_color"
     :background "ns_selection_bg_color")
    (((class color) (min-colors 88) (background light))
     :background "lightgoldenrod2")
    (((class color) (min-colors 16) (background dark))
     :background "blue3")
    (((class color) (min-colors 16) (background light))
     :background "lightgoldenrod2")
    (((class color) (min-colors 8))
     :background "blue" :foreground "white")
    (((type tty) (class mono))
     :inverse-video t)
    (t :background "gray"))
  "Basic face for highlighting the region."
  :version "21.1"
  :group 'basic-faces)

>
> First of all, the name :distant-foreground is not intuitive.  What does
> "distant" mean in this context?
>

The same as in any other context, far removed from something else, i.e. the background.

> Also, this feature has one ugly consequence.  Previously, the `default'
> face must have all its face attributes specified, but now its
> :distant-foreground face is unspecified.

Default face does not need to have its font specified, so this is not new.

>
> Besides that, the implementation seems rather incomplete.  The Customize
> interface, `modify-face', `face-spec-reset-face', and other parts of
> Emacs haven't been updated for the existence of this face attribute.

That is on purpose.  It is supposed to be automatically calculated.

> It's unclear what functions like `face-foreground' should now do if
> there's a :distant-foreground.
>

No it is not.

> This all sounds like an invitation for more bugs.  In my opinion, this
> feature is a bad idea.

All new features invite new bugs, so are you saying we should never add new features?
Your opinion is not very interesting, but if you have core for an alternative approach that would be interesting.

        Jan D.


Reply | Threaded
Open this post in threaded view
|

RE: About the :distant-foreground face attribute

Drew Adams
> > What is the purpose of this face attribute, newly introduced for
> > 24.4?
>
> Too lazy to read documentation?
>
> "`:distant-foreground'
>      Alternative foreground color, a string.  This is like
>      `:foreground'
>      but the color is only used as a foreground when the background
>      color is near to the foreground that would have been used.
>      This is useful for example when marking text (i.e. the region
>      face).
>      If the text has a foreground that is visible with the region
>      face, that foreground is used.  If the foreground is near the
>      region face background, `:distant-foreground' is used instead
>      so the text is readable."

I see.  And just how does a user override this automatic "cleverness"?
How can a user really make her preference for the face take effect?

This kind of DWIMity should always allow users to take control back,
and preferably easily.  What you think might be best for all users
all the time might not be what some user thinks is best for herself.

And what about all of the existing code that tests :foreground or
otherwise expects it to reflect the actual foreground used?  Is that
code broken now, because Emacs substitutes a :distant-foreground
color behind its back?  Must all such code now change to test first
one and then the other?

When was this design OK'd (and why)?

> > First of all, the name :distant-foreground is not intuitive.  What
> > does "distant" mean in this context?
>
> The same as in any other context, far removed from something else,
> i.e. the background.

I agree with Yidong about the name.  This is apparently a fallback,
alternative color, when (you) think the color specified by the
user or program is inappropriate.

> > Besides that, the implementation seems rather incomplete.  The
> > Customize interface, `modify-face', `face-spec-reset-face', and
> > other parts of Emacs haven't been updated for the existence of
> > this face attribute.
>
> That is on purpose.  It is supposed to be automatically calculated.

So what?  All the more reason to bring it out into the open, so
users can know about it (and try to find some way to work around it,
if they like).

> > It's unclear what functions like `face-foreground' should now do
> > if there's a :distant-foreground.
>
> No it is not.

Yes it is.  See above.  Search the distributed code and the Internet
for uses of "foreground" in Emacs Lisp code.  How much of that code
now needs to be modified to accommodate this gratuitous change.

Was there a real problem, reported by a real user, that this change
attempts to fix?  Or is this just someone's clever brainchild for
making Emacs smarter?

> > This all sounds like an invitation for more bugs.  In my opinion,
> > this feature is a bad idea.

+1

> All new features invite new bugs, so are you saying we should never
> add new features?

All new features should be proposed and discussed, before being cast
into the product.  That's my humble opinion.

> Your opinion is not very interesting, but if you have core for an
> alternative approach that would be interesting.

Why is any approach needed?  What is the (real) problem that needs
solving?

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Eli Zaretskii
> Date: Tue, 7 Jan 2014 09:28:05 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: emacs-devel <[hidden email]>
>
> All new features should be proposed and discussed, before being cast
> into the product.

This one was.  It solved a bug.

> Why is any approach needed?  What is the (real) problem that needs
> solving?

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15668.

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Joel Mccracken
In reply to this post by Drew Adams
It seems like "contrast" could be used to explain the difference in a more intuitive way.

On Jan 7, 2014, at 12:28 PM, Drew Adams <[hidden email]> wrote:

>>> What is the purpose of this face attribute, newly introduced for
>>> 24.4?
>>
>> Too lazy to read documentation?
>>
>> "`:distant-foreground'
>>     Alternative foreground color, a string.  This is like
>>     `:foreground'
>>     but the color is only used as a foreground when the background
>>     color is near to the foreground that would have been used.
>>     This is useful for example when marking text (i.e. the region
>>     face).
>>     If the text has a foreground that is visible with the region
>>     face, that foreground is used.  If the foreground is near the
>>     region face background, `:distant-foreground' is used instead
>>     so the text is readable."
>
> I see.  And just how does a user override this automatic "cleverness"?
> How can a user really make her preference for the face take effect?
>
> This kind of DWIMity should always allow users to take control back,
> and preferably easily.  What you think might be best for all users
> all the time might not be what some user thinks is best for herself.
>
> And what about all of the existing code that tests :foreground or
> otherwise expects it to reflect the actual foreground used?  Is that
> code broken now, because Emacs substitutes a :distant-foreground
> color behind its back?  Must all such code now change to test first
> one and then the other?
>
> When was this design OK'd (and why)?
>
>>> First of all, the name :distant-foreground is not intuitive.  What
>>> does "distant" mean in this context?
>>
>> The same as in any other context, far removed from something else,
>> i.e. the background.
>
> I agree with Yidong about the name.  This is apparently a fallback,
> alternative color, when (you) think the color specified by the
> user or program is inappropriate.
>
>>> Besides that, the implementation seems rather incomplete.  The
>>> Customize interface, `modify-face', `face-spec-reset-face', and
>>> other parts of Emacs haven't been updated for the existence of
>>> this face attribute.
>>
>> That is on purpose.  It is supposed to be automatically calculated.
>
> So what?  All the more reason to bring it out into the open, so
> users can know about it (and try to find some way to work around it,
> if they like).
>
>>> It's unclear what functions like `face-foreground' should now do
>>> if there's a :distant-foreground.
>>
>> No it is not.
>
> Yes it is.  See above.  Search the distributed code and the Internet
> for uses of "foreground" in Emacs Lisp code.  How much of that code
> now needs to be modified to accommodate this gratuitous change.
>
> Was there a real problem, reported by a real user, that this change
> attempts to fix?  Or is this just someone's clever brainchild for
> making Emacs smarter?
>
>>> This all sounds like an invitation for more bugs.  In my opinion,
>>> this feature is a bad idea.
>
> +1
>
>> All new features invite new bugs, so are you saying we should never
>> add new features?
>
> All new features should be proposed and discussed, before being cast
> into the product.  That's my humble opinion.
>
>> Your opinion is not very interesting, but if you have core for an
>> alternative approach that would be interesting.
>
> Why is any approach needed?  What is the (real) problem that needs
> solving?
>


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Eli Zaretskii
In reply to this post by Jan D.-2
> Date: Tue, 7 Jan 2014 10:44:26 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> > > All new features should be proposed and discussed, before being
> > > cast into the product.  That's my humble opinion.
> >
> > This one was.  It solved a bug.
>
> The new feature was not proposed on emacs-devel and discussed.

emacs-devel is not the only place where Emacs development is
discussed.  The bug list and the bug reports are another.

> IMO, the implementation, and probably the feature itself, is not
> TRT.

Sorry, I disagree.  I think it's exactly right.


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Eli Zaretskii
In reply to this post by Jan D.-2
> Date: Tue, 7 Jan 2014 11:06:15 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> > > IMO, the implementation, and probably the feature itself, is not
> > > TRT.
> >
> > Sorry, I disagree.  I think it's exactly right.
>
> And what do you say about code that expects that a face's
> `foreground' attribute actually reflects the face's current
> foreground appearance?

I don't understand the issue, but regardless, the fact that bugs exist
(if they exist) doesn't mean the design and the general implementation
are flawed.

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Chong Yidong
In reply to this post by Jan D.-2
Jan Djärv <[hidden email]> writes:

> Too lazy to read documentation?
>
> "`:distant-foreground'
>      Alternative foreground color, a string.  This is like `:foreground'
>      but the color is only used as a foreground when the background
>      color is near to the foreground that would have been used.  This
>      is useful for example when marking text (i.e. the region face).
>      If the text has a foreground that is visible with the region face,
>      that foreground is used.  If the foreground is near the region
>      face background, `:distant-foreground' is used instead so the text
>      is readable.

I read that, but the explanation was pretty darn cryptic.  But OK: from
your message, I gather that this feature was introduced to deal with the
problem which setting the `region' face from system (GTK or NS)
settings.

But is there any other even vaguely envisioned usage?  Because, as
explained before, there are better ways to deal with this problem than
something so intrusive as defining a new face attribute.

>> First of all, the name :distant-foreground is not intuitive.  What does
>> "distant" mean in this context?
>>
>
> The same as in any other context, far removed from something else,
> i.e. the background.

Things that are "distant" are in the BACKGROUND, so "distant foreground"
sounds tautological.  The fact that there isn't a good name for this
face attribute is an indicator that it's not well-conceived.

The feature does not fit well with the design of the rest of the
face-handling code.  We already have a mechanism for checking to see
when to use a particular face: the DISPLAY element in a face spec.  The
:distant-foreground face attribute, by its very existence, is redundant
with what the DISPLAY element was meant to do.  This adds extra
complexity to the design, for no good reason.

If you need to check for a background, the right thing would be to
extend the DISPLAY feature to do what you need.  For example, a DISPLAY
element of `(background dark)' is used to test for a dark background.
Maybe what you want is to be able to specify a color in place of `dark',
which would mean a background close to that color.

>> Also, this feature has one ugly consequence.  Previously, the `default'
>> face must have all its face attributes specified, but now its
>> :distant-foreground face is unspecified.
>
> Default face does not need to have its font specified, so this is not
> new.

M-: (face-attribute 'default :font) RET
  => #<font-object "-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1">

M-: (face-attribute 'default :distant-foreground) RET
  => unspecified


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Jan D.-2
In reply to this post by Jan D.-2
> If you need to check for a background, the right thing would be to
> extend the DISPLAY feature to do what you need.  For example, a DISPLAY
> element of `(background dark)' is used to test for a dark background.
> Maybe what you want is to be able to specify a color in place of `dark',
> which would mean a background close to that color.

Patches welcome.

        Jan D.


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Darren Hoo
In reply to this post by Chong Yidong
I originally reported bug 15668

Just FYI, the `font-lock on region' thing is still not available in these
bundled themes: wombat, wheatgrass, misterioso.


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Eli Zaretskii
In reply to this post by Chong Yidong
> From: Chong Yidong <[hidden email]>
> Date: Wed, 08 Jan 2014 05:57:41 +0800
> Cc: emacs-devel <[hidden email]>
>
> The feature does not fit well with the design of the rest of the
> face-handling code.  We already have a mechanism for checking to see
> when to use a particular face: the DISPLAY element in a face spec.  The
> :distant-foreground face attribute, by its very existence, is redundant
> with what the DISPLAY element was meant to do.  This adds extra
> complexity to the design, for no good reason.
>
> If you need to check for a background, the right thing would be to
> extend the DISPLAY feature to do what you need.  For example, a DISPLAY
> element of `(background dark)' is used to test for a dark background.
> Maybe what you want is to be able to specify a color in place of `dark',
> which would mean a background close to that color.

I don't understand this criticism.  How is this attribute different
from min-colors?

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Chong Yidong
Eli Zaretskii <[hidden email]> writes:

>> The feature does not fit well with the design of the rest of the
>> face-handling code.  We already have a mechanism for checking to see
>> when to use a particular face: the DISPLAY element in a face spec.  The
>> :distant-foreground face attribute, by its very existence, is redundant
>> with what the DISPLAY element was meant to do.  This adds extra
>> complexity to the design, for no good reason.
>
> I don't understand this criticism.  How is this attribute different
> from min-colors?

The min-colors feature doesn't involve adding an extra face attribute.
The analogy would be if there was a :low-color-foreground face attribute
which would override :foreground on low-color displays.  That would be
ugly, as I hope you agree.

OK, after poking around a bit I understand the problem better.  You want
to be free to set face background colors without worrying about making
text illegible (which can be difficult to figure out ahead of time,
because of face inheritance etc).  So here's a proposal:

Change the feature so it applies to all faces, but in a configurable
way.  Introduce a new Lisp variable, `face-minimum-contrast', which
specifies the minimum allowed contrast between the background and
foreground of any face (or nil, which means to disable the feature).  If
the contrast of a face is lower than specified, the foreground color is
adjusted (say, by changing its V component) to conform to the minimum
contrast.

This would avoid having to introduce a :distant-foreground attribute for
all faces, only to use that attribute for just one face (`region') and
for one special purpose (to cope with the GTK selection color).  It
would handle the generic class of problems involving text becoming
illegible, such as due to bad themes.

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Jan D.-2
Hi.

8 jan 2014 kl. 06:24 skrev Chong Yidong <[hidden email]>:

> Change the feature so it applies to all faces, but in a configurable
> way.  Introduce a new Lisp variable, `face-minimum-contrast', which
> specifies the minimum allowed contrast between the background and
> foreground of any face (or nil, which means to disable the feature).  If
> the contrast of a face is lower than specified, the foreground color is
> adjusted (say, by changing its V component) to conform to the minimum
> contrast.
>

On Gtk and NS the region color to use is in that case specified by the system and should not be generated by modifying a color component.  How do you specify that?
Also, it isn't the contrast between the background and the foreground of a face, but the contrast between the background and foreground to be rendered, which comes from different faces in the case at hand.

> This would avoid having to introduce a :distant-foreground attribute for
> all faces, only to use that attribute for just one face (`region') and
> for one special purpose (to cope with the GTK selection color).  It
> would handle the generic class of problems involving text becoming
> illegible, such as due to bad themes.

distant-foreground can be used on any face, it just isn't.

        Jan D.


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Chong Yidong
Jan Djärv <[hidden email]> writes:

> On Gtk and NS the region color to use is in that case specified by the
> system and should not be generated by modifying a color component.
> How do you specify that?

The reason this feature was introduced was so that Emacs could get away
with not using the specified *_foreground_color, and use the underlying
face color instead.  It is inconsistent to suddenly want to start
honoring it.

> Also, it isn't the contrast between the background and the foreground
> of a face, but the contrast between the background and foreground to
> be rendered, which comes from different faces in the case at hand.

Yep.

>> This would avoid having to introduce a :distant-foreground attribute for
>> all faces, only to use that attribute for just one face (`region') and
>> for one special purpose (to cope with the GTK selection color).  It
>> would handle the generic class of problems involving text becoming
>> illegible, such as due to bad themes.
>
> distant-foreground can be used on any face, it just isn't.

Yep, not sure what your point is.

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Jan D.-2

8 jan 2014 kl. 10:52 skrev Chong Yidong <[hidden email]>:

> Jan Djärv <[hidden email]> writes:
>
>> On Gtk and NS the region color to use is in that case specified by the
>> system and should not be generated by modifying a color component.
>> How do you specify that?
>
> The reason this feature was introduced was so that Emacs could get away
> with not using the specified *_foreground_color, and use the underlying
> face color instead.  It is inconsistent to suddenly want to start
> honoring it.

Honoring what?  Your statement makes no sense.  I'm talking about the fact that your proposal does not do what the current implementation does.
In your proposal, the foreground to use (distant foreground) would be calculated by Emacs.
In the current implementation, the foreground to use is specified by the system (Gtk+/NS).
How do you specify that in your proposal?

        Jan D.


Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Stefan Monnier
In reply to this post by Chong Yidong
> way.  Introduce a new Lisp variable, `face-minimum-contrast', which
> specifies the minimum allowed contrast between the background and
> foreground of any face (or nil, which means to disable the feature).

Some packages use a face with foreground=background so as to hide the
text (while still taking up space).  IOW this "make sure there's enough
contrast" should not apply to all faces.


        Stefan

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Chong Yidong-2
In reply to this post by Jan D.-2
Jan Djärv <[hidden email]> writes:

> Honoring what?  Your statement makes no sense.  I'm talking about the
> fact that your proposal does not do what the current implementation
> does.  In your proposal, the foreground to use (distant foreground)
> would be calculated by Emacs.  In the current implementation, the
> foreground to use is specified by the system (Gtk+/NS).  How do you
> specify that in your proposal?

Why is the current behavior TRT?  You are already choosing to ignore
gtk_selection_fg_color under some (arbitrarily hard-coded)
circumstances.

So if you care about obeying gtk_selection_fg_color, why not just set it
to :foreground?  When gtk_selection_bg_color is in use, we might as well
use gtk_selection_fg_color with it.  Users who want a region background
color that works properly with font lock might as well disable the GTK
selection color stuff (it's unfortunate that it's the default, but oh
well).

Reply | Threaded
Open this post in threaded view
|

Re: About the :distant-foreground face attribute

Jan D.-2
Hi.

8 jan 2014 kl. 15:49 skrev Chong Yidong <[hidden email]>:

> So if you care about obeying gtk_selection_fg_color, why not just set it
> to :foreground?  When gtk_selection_bg_color is in use, we might as well
> use gtk_selection_fg_color with it.  Users who want a region background
> color that works properly with font lock might as well disable the GTK
> selection color stuff (it's unfortunate that it's the default, but oh
> well).


You obviously don't understand the issue, so I'll try to be very clear.

1) Font lock uses faces with specified fore- and background.
2) When text is marked with the mouse, the region face is applied on (overrides) the font lock face.
3) If the region face blindly uses the foreground from the region face (as per your suggestion), for example gtk_selection_fg_color, font lock is lost.  That is what bug 15668 is about.
4) On the other hand, if we always ignore the region foreground color, and use the font lock foregrpund color bug 15668 would be solved.  However, if the font lock foreground and the region background is similar, text is not readable.  So in that case, distant-foreground is used.
5) When making a theme, I suspect one wishes to specify all colors, not use some arbitrary generated color, which most certainly don't match the theme.  So we need a way to specify that color, hence distant-foreground.

Your proposals:
1) Use the selection foreground color when the selection background is used
=> Bug 15668.

2) Disable GTK selection color stuff
This might lead to unreadable text as the region bacground may be close to the foreground.

There is no "region background color that works properly with font lock" for all font lock faces, because the colors in font lock faces are unknown, esp. with themes.

If you can get your scheme to let theme designers specify all colors without adding a new face parameter, via the display property somehow, that could be something.  Not that it would make anything simpler or a better design, it just sounds more involved to me.  Using generated colors is right out IMHO, it makes themes impossible to fully specify.

        Jan D.


Reply | Threaded
Open this post in threaded view
|

RE: About the :distant-foreground face attribute

Drew Adams
In reply to this post by Chong Yidong-2
The foreground attribute for a face should always reflect the actual
appearance of that face (in isolation - this is not about the effects
of combining faces etc.).  Anything different from that is asking for
trouble.

IIUC, this change was made because on some platforms the default
color for the `region' face background is inappropriate, given
the default color for its foreground.

To me, that sounds like the kind of thing that Eli recently
declared to be not-an-Emacs-problem.  But so be it - if Emacs can
reasonably work around that problem, why not?

If Emacs wants to make an attempt to compensate for that bad
defaulting behavior, then I would think that the right approach
would be to automatically tweak the color of the `region' face's
foreground attribute itself.  And preferably only for those
situations where the problem actually arises.

Adding a variable, as Yidong suggested, just spreads the
pollution of this misguided fix across all faces.  And it still
does not sync the attribute value with the appearance.  What the
attribute says you should get is not what you get.  The color is
being changed behind the back of the face spec.

If the face attribute value does not reflect the face appearance
for an attribute, code that examines that attribute, e.g., to base
its behavior on what the face's foreground is, will likely not DTRT.
And code that modifies the face's foreground attribute will likewise
likely not do what it is expected to do.  Code becomes less
transparent and dependable.

Foreground attribute and actual foreground should be and remain
one-to-one - no surprises (again, not counting face mergings etc.).

Can't you please find a way to keep the foreground attribute in
sync with the actual foreground color you need in this scenario?
Can't you perform whatever machinations are needed to change the
foreground attribute itself so that you get the visual effect
needed?

OK, so changing the attribute overrides whatever setting the user
might fix for the attribute.  But that would be done only when
the problem arises.  And it should be done only with the user's
permission.

IOW, I agree with Stefan (almost mentioned it myself) that users
and Lisp code should be able, for whatever reason, to specify
that the foreground and background for a given face are the
exact same color.  IOW, any automatic overriding of what the
face definition specifies should be optional, under user control.

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.)

The important thing is to preserve the correspondence between
each face's current appearance and its current attribute values.

Reply | Threaded
Open this post in threaded view
|

RE: About the :distant-foreground face attribute

Drew Adams
In reply to this post by Jan D.-2
> 1) Font lock uses faces with specified fore- and background.
> 2) When text is marked with the mouse, the region face is applied on
>    (overrides) the font lock face.

As it should.

> 3) If the region face blindly uses the foreground from the region
>    face (as per your suggestion), for example gtk_selection_fg_color,
>    font lock is lost.  That is what bug 15668 is about.

Font lock is not "lost".  Font-lock highlighting is covered by the
region highlighting.  And that is what should happen.  This "bug"
should not have been "fixed", IMHO.

This is what text selection highlighting is all about.  A user needs
to be able to see which text is highlighted - each selected char.

And you should not assume that font-locking affects only foregrounds.
Are you going to make the same "fix" for backgrounds also, so that
selecting text lets font-locked (or otherwise highlighted) backgrounds
show through the region highlighting?  And if font locking highlights
both the foreground and background of a character?  Bingo - you cannot
see which text you have selected.

This kind of change seems so misguided.  Hard to believe we've
arrived here.

1234 ... 7