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

[Daniel Colascione]

On 01/13/2014 05:45 PM, Stefan Monnier wrote:
> > > > If you want the :distant-foreground behavior, it can be accommodated
> > > > in this patch. This patch also permits other schemes that some users
> > > > might find more useful. We should push policy to user customization
> > > > when possible instead of hardcoding policy in the logic of
> > > > face attributes.
> > > 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.
> > You can write something like that in my setup --- we actually
> > call :contrast-function on every face realization. There's no reason it has
> > to act only on certain conditions, although that's what all the existing
> > implementations do.
>
> There are some differences, tho, w.r.t what the function sees:
> does it see the fully merged face, or does it only see the face
> merged up to the point where the filter appears.

Indeed. Well, let's honor the long tradition of choosing the policy 
that's easier to implement. :-)

We can support our hypothetical :filter (which we should rename 
:post-realize-filter) without too much change to the face logic using 
this scheme:

1) Define LFACE_FILTER_FUNCTION as a possibly-empty list of filter functions

2) When we combine faces A and B, A+B's LFACE_FILTER_FUNCTION is the 
concatenation of A's filter list and B's filter list. As an exception,
if B's filter list is of the form (t . OVERRIDE-FILTER-LIST), then A+B's 
filter list is just OVERRIDE-FILTER-LIST.

3) On realization, we pass the resulting face attributes through each 
filter function, then use the resulting attributes for display.

Later, if we need to, we can add a regular :filter that works 
face-by-face, like height.