Re: +face-remapping-20040505-0.patch

[Miles Bader]

Kevin Rodgers <address@hidden> writes:
>  >>Face-remapping only affects redisplay; `face-attribute' will not see it.
>
> No, it seems wrong to me as well.  Doesn't face-attribute exist to allow
> the programmer to find out how a face will actually look?

No.

It exists to let you find out the attributes of a face, the inverse of
`set-face-attribute' -- it's a fairly low-level operation.  Note that by
default, it will return `unspecified' for attributes that aren't
_directly_ specified in a face, and this is intentional.

The appearance of text, on the other hand, is not typically due to one
face, but rather the merging of several faces.

The `face-attribute' function _does_ have an optional argument to do
face-merging on the result, so perhaps an additional argument might be
added to do remapping too, analoguous to the current INHERIT argument.
E.g.:

   (face-attribute FACE ATTRIBUTE &optional FRAME INHERIT REMAP)
   ...
   If REMAP is nil, the default frame-global face definitions will be used.
   If REMAP is t, faces will be remapped according to the current
     definition of `face-remapping-alist'.
   If REMAP is an alist, faces will be remapped as if
     `face-remapping-alist' had that value.

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia