RE: Problems with setting face attributes for specific frames

[Drew Adams]

> In this message I propose a change in how faces work, in response
> to the analysis of this bug.
>
> The logic in `frame-set-background-mode' is correct for the case
> of customizing `frame-background-mode'.  It distinguishes the
> faces that match their defface specs from those for which attributes
> were overridden (perhaps by calling `set-face-attribute').
> It recalculates the former in the proper new way from the defface,
> and it leaves the latter alone.
>
> However, the logic is wrong for this case, where
> `frame-set-background-mode' is called from `set-background-color'.  If
> my analysis is correct, by the time `frame-set-background-mode' is
> called, the new background color has already been installed in the
> frame, but most faces still use the old one, so they do not match
> their specs any more.
>
> I think the code that handles faces needs to be cleaned up to keep
> user-specified single-frame face attributes separately from the
> actual face attributes deduced from the combination of all sources.
> That is the only way to deduce new actual face attributes correctly
> after changes in some of the parameters that the deduction is done from.
>
> Or perhaps we should get rid of using `set-face-attribute' to specify
> face attributes on a frame.
>
> Not many packages call `set-face-attribute'.  There are just
> two in Emacs that use it with a frame: ediff-wind.el
> and mac-win.el.  pc-win.el calls it via `set-face-foreground'
> and `set-face-background'.  The obsolete hilit19 package
> calls `set-face-font', but we could delete that.

I don't understand all of what you're proposing or what the problem is that
you're fixing. I think you're proposing removing the FRAME arg from
`set-face-attribute' (perhaps among other changes). Is that correct?

I do use `set-face-attribute' in some of my code, but always with a nil
FRAME arg, so that would be OK by me. I assume that we would still have
`modify-face', in any case, right?