RE: facemenu-unlisted-faces

[Drew Adams]

              Yes, the uses we're talking about here involve
              applying a color or a style... to buffer text.
              They don't really involve faces. Users making
              text bold, or removing boldness from text,
              should not have to think in terms of the "bold"
              and "default" faces - they should think
              only in terms of text properties.

          For "bold", we could think of it either way.
          Why do you think one is better than the other?

        For *any* face that affects only the foreground, we could
        think of it in either way. If the face name corresponds
        to the foreground appearance (as does "bold"), then it
        really doesn't matter.

    That is true.  I do not see where that point leads, though.

You singled out "bold". I pointed out that boldness is no different from
other "properties"/"styles"/"attributes" (I'm using quotes now, so people
will know I'm abstracting from the implementation). As you put it, "we could
think of [any of them] either way." As I said, "it really doesn't matter."

What matters is that thinking of applying some fixed, unchangeable
"property" to text is simpler than thinking of applying a _face_, which is
something:

 - specific to Emacs (so, new to newbies)
 - complex, in many ways
 - changeable, customizable

        For "fixed pitch", I think that can only be considered as a face.

        Consider it a style, and treat it like bold, italic, and underline.
        Actually, like bold and italic, it is a font property.

    No, it isn't.  That won't work.  We cannot make a fixed-pitch variant
    of any given face.

Yes, but we could do what applying face `fixed-pitch' does now: simply
impose :font-family Courier. That would do no better or worse than what
applying the face does now, except in this sense: The user would not need to
know or think about faces at this level, and the "property" that is applied
is a constant one(always :font-family Courier). If you discount the latter
difference, OK. The main point is that a user's conceptual model can be
simpler - there is no need to introduce faces at this point.

        Even when users highlight text (changing its background),
        they don't think of the text (characters) changing color
        in any way; they think that the background has changed
        color, but they don't consider the background to be a
        property of the text.

    That may be true, but how does that relate to the menu structure?
    I do not see the connection.

It's a minor point.

1. Changes to the background are less common than changes to the foreground.

2. One less submenu at the top level: Color vs Foreground Color and
Background Color.

3. New users looking to change the color, by which they mean foreground
color, would look for and find Color in the menu. Users looking to change
the background color (which is less common) would still find that, under
Color > Background.

    I see no possible benefit in putting the menu of background colors
    underneath the menu of foreground colors.

Not "underneath the menu of foreground colors." Underneath the Color menu.
Background would be a submenu at the same level as the foreground colors.
Foreground coloring would be privileged because it is more common. That's
all.

The only reason to do this is to make background coloring less obtrusive,
since it is less frequent. There is already a lot of stuff at the top level
of the Text Properties menu. Again, it's a very minor point.


Really, I just threw out a few menu suggestions. Do with them what you will.
I take it as a compliment that so much attention has been given to my
suggestions, but I take it as poor communication on my part that so much of
the response has seemed to miss the main suggestions - sorry about that.
After all of this dialog, I'd ask that you go back and read the initial menu
suggestions, with updated understanding of what I meant (sorry for any
confusion), and then decide whether you like any of the suggestions.