RE: facemenu-unlisted-faces

[Drew Adams]

        It is far more natural to click Bold a second time to turn
        off boldness for the selection than it is to think of
        applying the `default' face to it.

    That is a good idea.  However, this is not the same as what you were
    talking about before.  This is an interface question.  You were
    talking about a conceptual quesion, whether to consider it a "face" or
    a "face attribute".

What the user does with an interface reflects the user's mental model of how
things work, which includes concepts of the objects s?he manipulates. Emacs
users (though perhaps not novices) will have a concept of "face", but that
concept is more complex and less usual than the concept of text property
(face attibute, text style, font property - whatever). In the latter case,
the user thinks in terms of properties that s?he applies to text.

In the case of faces, a user must have something more complex in mind:

 - A face is a variable, whose value can change. Its name, if it
   describes the appearance, might lie (a face named `blue' might
   be red).

 - A face can have multiple properties, some of which users are
   not used to associating with displayed text. A simple example
   is background color, as I mentioned - that is not usually
   (conceptually) associated with the displayed text.

        The fact that face named "fixed pitch" has a fixed pitch is
        a happy happenstance.

    It is not happenstance.

You mean that that association (face name and font family) was deliberate,
right?

It is a happenstance in the sense that the name happens to reflect the
appearance - until someone changes that association. If the face name were
Foo or Blue, or if the font family of that face were changed to helvetica,
then it would not be such a happy happenstance. With a face, you cannot
depend on the name to indicate the appearance - the association of name and
appearance is, at any given time, a happenstance.

Much more importantly, it is a happenstance for the user. The user is
interested in the appearance, not in the fact that it is a face. All the
user wants to do is make some text be fixed pitch (or green or bold or
blinking or metalic or...).

You say, "We've got this nifty template here called a face that will do that
for you." The user says, "template? - face?"  You say, "Sure, a face has all
kinds of neat properties (attributes): foreground, background, font
family,.... And it is a variable - you can change its properties, and then
all the text with that face will reflect that change. The user says, "I just
want to make this text be fixed pitch." You say, "Sure, but you need a face
for that - we have one here just for that job, `fixed-pitch'."

The point is, you don't need a face for that - at least not conceptually,
from the user's point of view. Introducing faces (here) just complicates the
UI for no gain. You stated, "For 'fixed pitch', I think that can only be
considered as a face."  That's wrong; the user need not jump through the
hoop of considering it a face - no more than s?he must do that for bold. If
s?he can think of applying boldness without conceiving of a bold face, she
can do likewise for applying fixed-pitchness.

How we actually implement "applying fixed-pitchness" is another story. We're
talking user mental model here - keep that as simple as possible, as long as
it is sufficiently accurate for the task at hand. At some point, it might be
that a user needs to know that the quality of fixed-pitchness was actually
"applied" by using a face - at that point, the concept can be introduced.

This (applying boldness etc.) is a very simple interaction for users. Occam
says not to make them conceive of more machinery than necessary to get the
job done, even if there is a wonderful wizard or a "machine a gaz" behind
the curtain.

    That's what the name is meant to be used for.

Sure it is (although faces are not constants). But most faces are not named
for their appearance; this is an exception. Introducing fixed-pitch *as a
face* unnecessarily complicates things conceptually, and creates an
exception in the UI. There is no reason for it. Let users think of it the
same way they think of boldness - as a text property (or as a font family -
see below).

A face is a variable; its value is not in any way tied to its name. Users
need to think about faces differently than they think about text properties.

Usually, when a user wants to make some text be fixed pitch, s?he thinks in
terms of changing the font or its style or its text properties (call it what
you will - we are talking about user conception here, not implementation or
formal definition). There is no notion of "face" in most UIs, and it is not
necessary to introduce it here either, just to let users apply a fixed pitch
to selected text. We can treat fixed pitch vs variable pitch the same way
boldness is treated - for the user.

There will still be a `Face...' menu item that lets users get to faces,
including fixed-pitch. We're not holding anything back from them. But simply
making some text be fixed pitch *requires* no notion of face.

          It is the monospace (fixed pitch) font property that a
        user wants to apply to text in this case,

    There is no such "font property".  Some fonts are fixed pitch, and
    some are not.

Some fonts are bold and some are not, also. Call it what you like. The point
is that font family is, like boldness, a text style, from a user point of
view. The fact that we have a face that uses that font family does not mean
that wanting to make text fixed pitch means wanting to use that face. How we
make the user's selection bold or fixed pitch is something s?he usually
doesn't care about. In most UIs, you simply select the text and pick a font
for it from a menu, or hit a Bold button.

Now, it's true that when you "apply fixed-pitchness" to some text its
appearance can change quite a bit. Another way to think about the change is
as a font change (which is what it really is). It's true that applying
boldness does not change the font family, while making text fixed pitch
usually does - font family is the only face attribute that fixed-pitch
defines, and fixed-pitch is the only one of the text "properties" in this
menu that involves the font family.

I have no quarrel with removing fixed-pitchness from the Text Properties
menu altogether (except as a face in the `Face...' display), and leaving it
available as a font family (e.g. Courier) in the font menu. My point is that
it *could* be handled simply as a text property (conceptually), and users
need not treat it as an exception - as a face, when they apply it.

I was only addressing fixed-pitch because you brought it up as being
impossible to use except as a face. My preference is to remove it from the
menu, but if you want it, it can be treated the same as boldness.