Re: 23.0.50; face-problems with multy-tty

[Richard Stallman]

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

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.

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.

I cannot see any other consistent way to handle them both.  If face
customization did not have conditionals, if all it did was specify a
value for each attribute, then the customizations would be
commensurable with the face attributes, and they could both set the
same values in a simple way.  But that is impossible with the
conditional face customizations that we have.

Does anyone else have any ideas about this?