[Top][All Lists]

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

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

From: Miles Bader
Subject: Re: +face-remapping-20040505-0.patch
Date: 12 May 2004 10:30:39 +0900

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?


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.

   (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.

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

reply via email to

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