Re: 23.0.50; face-problems with multy-tty

[bojohan+news@dd.chalmers.se (Johan Bockgård)]

Richard Stallman <rms@gnu.org> writes:

> 	(set-face-attribute 'font-lock-string-face nil :foreground "yellow")
>
> 	(custom-set-faces
> 	 '(font-lock-string-face
> 	   ((((class color) (background light)) (:foreground "red"))
> 	    (((class color) (background dark)) (:foreground "blue")))))
>
> 	;; `C-x 5 2' uses a yellow font-lock-string-face.
>
> I am not convinced that is a bug.
>
> The new-frame default face attributes override customizations because
> they are usually set by programs during a session, whereas
> customizations are usually set semipermanently.  In that kind of case,
> it is right for the default face attributes to take precedence.

I'm not convinced. The behavior that "new-frame default face attributes
override customizations" is only two weeks old. It didn't use to work
like that (see below).

> Customizations can also be made within a session. In that case, it is
> not clear which should take precedence.
>
> Thus, the current precedence order seems better, overall, than the
> opposite order.
>
> As long as we stick with this order, we should do it consistently.
> So the init file you showed should produce the results it produces.
> If you don't like it, don't do that.

It wasn't an example of a real init file. The case I'm worried about is
when you want to reset the faces from the init file with `C-x C-e' on
the custom-set-faces form (or by loading the file).

> Another consistent possibility is that the new-frame default face
> attributes and face customizations have the same precedence.  But the
> only consistent way to do that is if each one erases the other, so you
> can only have one of them.  So if you customize the face, that clears
> out all new-frame default face attributes, and if you set a new-frame
> default face attribute, that clears the customization.

Note that this is how it already worked before the recent changes.
custom-set-faces used to operate by changing the new-frame defaults. The
problem is that that doesn't distinguish between different kinds of
frames. Now custom-set-faces sets the attributes per frame (via
face-spec-set), but it needs to clear the new-frame defaults too.

-- 
Johan Bockgård