Re: About the :distant-foreground face attribute

[Josh]

On Thu, Jan 9, 2014 at 9:05 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Chong Yidong <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Fri, 10 Jan 2014 00:15:00 +0800
>>
>> Eli Zaretskii <address@hidden> writes:
>>
>> >> 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.
>> >
>> > I'm not sure I see the ugliness, please elaborate.
>>
>> One face attribute should govern one aspect of how the face is
>> displayed.  In some cases, it may be hard to avoid having multiple
>> attributes with overlapping effects, but the results are not pretty.
>> For example, the interactions between :family, :foundry and :font have
>> been a source of annoyance over the years.  Introducing another such
>> situation should, in my view, be avoided as far as possible.
>>
>> An example of a face attribute that handles things right is the :height
>> attribute.  An absolute height is given by an integer, while a relative
>> height can be specified by a float.  Allowing both in a single attribute
>> is good, because absolute height and the relative height are just
>> different ways to specify height.  We don't have a :height and a
>> separate :relative-height attribute.
>
> If you are arguing for a change in the syntax of :foreground such that
> it could convey the information about both the "normal" color, and the
> alternate color to be used when the background is too similar to that
> "normal" color, then I agree it will probably be a nicer and cleaner
> feature.  But that means :foreground will no longer be a simple
> string, but some more complex data structure, e.g. a list.
>
>> If I cannot convince anyone that there is a problem here, then forget
>> it.
>
> Don't give up just yet ;-)
>
> The solution should be able to cope with the need to dynamically
> decide which color is used as a foreground, based on the current
> background.  It also needs to support the possibility that a face will
> want to force use of a specific fixed foreground color, regardless of
> the background.  (Jan, did I miss some additional requirements?)  If
> you can propose a cleaner solution that satisfies these requirements,
> please do, and let's discuss that.

Instead of explicitly specifying alternative foreground colors,
whether by introducing a new face attribute or extending the
current :foreground attribute, perhaps we could introduce a new
`minimum-color-distance' user preference that would be used
something like this:

  (defun choose-foreground-color (fg bg minimum-color-distance)
    (if (or (> (color-distance fg bg) minimum-color-distance)
            ;; ^^^ foreground and background are sufficiently different
            (= fg bg))
            ;; ^^^ special case for text invisibility via fg==bg
        fg ;; preferred foreground color is ok; use it
      ;; otherwise, compute new foreground color -- not necessarily
      ;; via logxor but somehow guaranteed to be distant from bg
      (cl-mapcar 'logxor fg bg)))

Though such computed colors are likely to be ugly, clash with color
themes, etc. this approach is less invasive than the others being
discussed and I think it accomplishes the primary goal of ensuring
that bad combinations of foreground and background colors cannot
render text illegible.

Josh