RE: facemenu-unlisted-faces

[Drew Adams]

    > And, partly for precisely the issue you raise, it is, in
    > general, not a good idea to have faces (e.g. `bold',
    > `fixed-pitch') whose names claim a certain
    > appearance. Face names like `dired-flagged' communicate what
    > the face is for, they don't communicate how it looks; they
    > are in the Emphasis camp, not the Bold camp.

    Faces like "fixed-pitch" exist because they offer a useful abstraction
    (some places really need a fixed-pitch face, to display a table or
    whatever), and consolidate a common bit of user-specific configuration
    data (_which_ fixed-pitch face to use) into a single face (many other
    places may indeed also define their own face, and inherit from
    `fixed-pitch').

Let me try to be clearer still.

As long as the limitations of appearance-oriented changes (e.g. apply
underlining to existing text) are recognized by users (e.g. they amount to
hard-coding appearance, and are not flexible wrt different media), then
there can be a place for such changes. This is one argument for clearly
separating them in the UI from, for example, face changes, which don't, in
general, prescribe a particular appearance.

Faces have these characteristics that are different from this approach:

 - they allow for merging and inheritance.
 - they combine multiple attributes in an easy-to-use bundle
 - they are variables -
   1) they can be changed by program or by Customize, and
   2) if you change the value, all occurrences change

Things that it might be argued are missing from the notion of face, to
achieve the full flexibility of "semantic" markup, are 1) the ability to map
faces in different ways to different appearances (or sounds or whatever) in
different media, 2) the ability to constrain the context of application of a
given face, and 3) the ability to define and add new face attributes
(possibly unrelated to appearance). I'm not saying that we need any of those
things; I'm just pointing out that the flexibility of semantic markup
(that's not the right word) invites more features.

You can define a face `dired-flagged' to represent flagged Dired files, and,
yes, that is specification at the semantic level, not the appearance level,
but the face so defined has, as its defining characteristics, properties,
such as foreground and background colors, that really apply only to
appearance within Emacs (and perhaps PostScript). (There are also a few
predefined non-appearance face attributes.)

You cannot define how `dired-flagged' should appear in different output
media. You cannot define the contexts where `dired-flagged' can legitimately
be applied - any text anywhere can be given this face. You cannot define new
face attributes (e.g. unrelated to appearance) that you can then use in the
definition of `dired-flagged'.

More to your point -

I agree that the flexibility of face definitions, their bundling effect, and
inheritance in particular, make them useful for appearance-oriented markup
also. Text properties alone don't provide this convenience. But for this use
of faces to be clean, it would be better to have another kind of face: a
constant face.

The intention would be that a constant face would remain constant, at least
wrt its appearance. This would be to text appearance what defconst is to
symbol value. (This principle could perhaps also be applied to
non-appearance attributes, but that's another discussion.)

IOW, the usefulness you describe for face `fixed-pitch' is an argument for
its existence as a face, but as a *constant* face. Since it is specifically
intended to have a constant appearance (its particular appearance is its
raison d'etre), changing its appearance should somehow be discouraged or
prevented. Richard termed changing its appearance "anomalous", but there is,
today, no mechanism to support or track that. Faces such as `bold' and
`fixed-pitch' should be in a different class from those such as
`dired-flagged'. The former are meant to have a constant appearance
definition (else anomaly); the latter are not.

I'm not suggesting we should necessarily have any kind of tight control
here; a defconst-like treatment would probably be sufficient. The
constantness of `defconst' amounts to little more than a doc admonition not
to change the value, and that's probably enough for constant faces too. The
point is to proclaim the intention, for any given face.

So, yes to the idea that being a face makes `fixed-pitch' more useful. But
it should be in a different class from faces, like `dired-flagged', that are
not meant to always look the same.