emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About the :distant-foreground face attribute


From: Chong Yidong
Subject: Re: About the :distant-foreground face attribute
Date: Mon, 13 Jan 2014 04:14:11 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

David Engster <address@hidden> writes:

>> I'm wondering: We already can set different face attributes depending on
>> DISPLAY's 'background' property, which can be 'light' or 'dark'. Say the
>> user is working with a 'dark' background by default, but we now detect
>> that one of the font-lock faces has not enough contrast when highlighted
>> by the region: why not simply switch to the face that is defined for
>> 'light' background instead?
>
> Hey look, a tumbleweed!
>
> I'm assuming everybody's simply stunned by my ingenious proposal?

This would not work with customized faces, because Custom sets them with
a DISPLAY spec of t by default.  Anyway, this proposal would be hard to
implement technically, because DISPLAY spec is handled (in Lisp) before
the foreground and background attributes are settled on (which takes
face inheritance into account and is done in C).

Instead, here's a compromise proposal:

- Allow :foreground to take the value of (fallback COLOR) or something
  like that, which would be equivalent to setting :foreground to
  unspecified and :distant-foreground to COLOR.

  (We still need a replacement term for "distant foreground".  As
  mentioned before, this term sounds nonsensical.)

- In order to avoid incompatibilities, set the :foreground of the
  `region' face to "*_selection_fg_color".  In other words, avoid using
  the above feature in the `region' face, at least for Emacs 24.4.

  The rationale is that (i) we can live with having a fixed foreground
  color for the `region' face, since that was the case in Emacs 24.3 on
  GTK anyway.  And (ii) not using this feature immediately gives
  third-party packages a "transition period" to adapt to its presence,
  without immediately failing by encountering it in a standard face.

If there are no objections, I can implement this.



reply via email to

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