Re: bind faces?

[Miles Bader]

"Drew Adams" <address@hidden> writes:
>     FWIW, you can do it very easily with my `face remapping' patch -- it
>     ends up being just a normal `let' -- but that's [not?] part of Emacs
> yet:
>        (let ((face-remapping-alist
>               (cons '(some-face . bold) face-remapping-alist)))
>          (read-string "blah: "))
>
> Sounds promising (though I'm not sure how it works or just what it does).
> Never heard of it. Will it be in Emacs 22? 23? Where is it available in the
> meantime?

It's sitting in my personal source tree; I can cons up a patch.

I don't know when it will go in, but I assume it will at some point.
RMS approved of the feature generally, but disagreed with some of the
implementation details, so I'll have to find the time to either work out
something that is both acceptable to him and maintains all desired
properties.

The essential idea is to make face realization dependent on a variable
binding (a "remapping alist" -- the simplest usage just allows you to
"bind" face names to point to other faces, but you can also bind faces
by feature).

Here's the description (the value you see here is because I have the
"default" face bound to "variable-pitch" in mail composition buffers):


face-remapping-alist is a variable defined in `C source code'.
Its value is 
((default variable-pitch))

Local in buffer *wide reply to Drew Adams*; global value is nil
Documentation:
Alist of face remappings.
Each element is of the form:

   (FACE REPLACEMENT...),

which causes display of the face FACE to use REPLACEMENT... instead.
REPLACEMENT... is interpreted the same way the value of a `face' text
property is: it may be (1) A face name, (2) A list of face names, (3) A
property-list of face attribute/value pairs, or (4) A list of face names
intermixed with lists containing face attribute/value pairs.

Multiple entries in REPLACEMENT... are merged together to form the final
result, with faces or attributes earlier in the list taking precedence
over those that are later.

Face-name remapping cycles are suppressed; recursive references use the
underlying face instead of the remapped face.  So a remapping of the form:

   (FACE EXTRA-FACE... FACE)

or:

   (FACE (FACE-ATTR VAL ...) FACE)

will cause EXTRA-FACE... or (FACE-ATTR VAL ...) to be _merged_ with the
existing definition of FACE.  Note that for the default face, this isn't
necessary, as every face inherits from the default face.

Making this variable buffer-local is a good way to allow buffer-specific
face definitions.  For instance, the mode my-mode could define a face
`my-mode-default', and then in the mode setup function, do:

   (set (make-local-variable 'face-remapping-alist)
        '((default my-mode-default)))).


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