RE: [PATCH] Re: About the :distant-foreground face attribute

[Drew Adams <drew.adams@oracle.com>]

> FWIW, I like the idea of being able to compute the color
> dynamically. I also would welcome a way to specify "color filters",
> e.g. a face which "darkens the foreground color".  IOW the equivalent
> of the floating-point :height settings, but for colors.

Instead of :contrast-function (since this should not be limited to
foreground contrast), I guess you are essentially arguing to generalize
this to a :filter face attribute with a function value that would take
the whole face into account, as it is currently defined, and would act
on whatever attributes it wants, to update (modify) the face.

Is that right?  If so, that is not a filter, which is something that
just rejects some individuals from a collection (applies a predicate).
That is a transformation.  The function-valued attribute would be
better named :transformer or :transform-function.

But why have only one such function for a given face - its designated
transformation function, cast in bronze as an attribute?  Why wouldn't
code just apply whatever transformations it wanted?

Daniel proposes that a :filter attribute value be a _list_ of
transformation functions.  But the same question arises: why favor
one list of such functions by putting into an attribute value.

The same questions can be posed for whatever foreground-enhancing
transformation you are currently envisioning.  Why have a face
attribute for that?  Why not just perform whatever foreground
modification your code thinks is needed, directly?  What is the value
in promoting that particular transformation function into a face
attribute? 

Is it to give users control over this feature by using Customize?
If so, why not do that as we usually do: provide your (hopefully
optional, hopefully opt-in) feature via a user option?  With the option
turned on by the user, your automatic foreground enhancing would take
effect for some list of faces (e.g. just `(region)').