Re: Faces applies to new frames

[Richard M Stallman <rms@gnu.org>]

I think we need to change the way faces are specified,
and use something that is (1) simpler and (2) predictable.
I've included a proposal below.

    The trouble is that the `font' frame parameter interferes with the
    normal semantics of Lisp faces.

The `font' frame parameter and face attribute were set up so that
people accustomed to using X could specify fonts using the usual
X font specification syntax.  But they make things more complex.

I suggest eliminating the `font' parameter frame and the `font' face
attribute, and replacing them with a function to set up a face
based on a font name.  That function will serve the purpose, and it
won't cause any complications.

    AFAIK, the main situation where setting face attributes via
    frame-parameters is useful/used is for things like
    minibuffer-frame-alist (where I use it to give a special font and
    background to my minibuffer-only frame(s)), and special-display-regexps.

Would buffer-based interfaces be good for these jobs?
They might be better in every way.

Perhaps we should eliminate the per-frame face attributes, and have
only per-buffer ways to alter faces from the global specifications.

One benefit of that is that it would avoid the uncertainty about
precedence, which we have now when both users and defaults can specify
face attributes at various levels.  It would be clear and natural that
any per-buffer face specification overrides the global ones,
regardless of who set either one of them.

In this design, we would have defface, and the custom settings
(perhaps themed), and the program-specified face specs that you can
set with `face-spec-set', plus per-buffer overrides of various kinds.
That's all -- there would be no other way of controlling face
appearance.

This would mean changing `set-face-attribute' to reject a nontrivial
FRAME argument, and to work by calling `face-spec-set'.

The deprecated and apparently unused way of calling `face-spec-set'
that involves specifying a FRAME would be desupported.

It would be necessary to design a new implementation for the existing
feature that you can write X resources to control face appearance.
The feature of frame-name-specific X resources could be eliminated.

xfaces.c should be totally rewritten.  The only cause of face
variation between frames would be in the different kinds of terminals.
So it would make sense to realize each face only once per terminal.