[Top][All Lists]

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

Re: 23.0.50; face-problems with multy-tty

From: Johan Bockgård
Subject: Re: 23.0.50; face-problems with multy-tty
Date: Mon, 24 Sep 2007 02:00:21 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (gnu/linux)

Richard Stallman <address@hidden> 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

reply via email to

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