RE: facemenu-unlisted-faces

[Drew Adams]

        Yes, the uses we're talking about here involve applying a
        color, or a style such as boldness or underlining, 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. But many face names (e.g.
`diff-hunk-header') do not speak to the appearance - color names do, as do
"bold", "italic", and "underline".

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.
There are only a few styles (Bold etc.) available, and they can be combined.
Just click a style to toggle it.

Novices are familiar with applying styles and colors to text. They are not
necessarily familiar with the Emacs notion of a face. If the more complex
notion of a face offers something additional for a particular part of the
UI, then we can introduce it there. If not, we should respect Occam's razor.
In the case of boldness and colors, there is no reason to introduce it.

It *can* be useful to apply a defined face to text, as I mentioned. That's
the purpose of menu-item Faces....

    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.

A face is essentially a variable - its foreground and background can be
changed, and its name is often related to its use, not its appearance (which
can be altered). The fact that face named "fixed pitch" has a fixed pitch is
a happy happenstance. It is the monospace (fixed pitch) font property that a
user wants to apply to text in this case, not necessarily the face "fixed
pitch".

        And yes, the fact that the current submenus Foreground
        Color and Background Color have only the entry Other...
        is a hint that they are not needed.

    They are not much needed TODAY because Emacs' WYSIWYG features are
    incomplete.  But they definitely will be needed once the features are
    adequate.  Therefore, this hint must be misleading.

*As submenus*, they are not needed today or tomorrow. As I showed, the same
thing those menus offer can be presented in a simpler way.

        Why not combine the three current menus, Faces, Foreground
        Color, and Background Color,

         Text Properties

           Style > Bold
                     Italic
                     Underline
           Color > Red
                     Green (and so on)
                     Other...
                     Background > Red
                                      Green (and so on)

    You've suggested (1) putting the Background Color menu under
    the Foreground Color menu and (2) adding some initial colors.

    I see no benefit in (1).

Most WYSIWYG editors do not even provide Background coloring as an option.
Applying a color means, to most users, applying it to the visible characters
themselves, that is, to the foreground, not to the background. Background
coloring (e.g. for highlighting) will be used less often. Users should see
"Color" in the menu (not Foreground and Background), and that should mean
foreground (because it means that to them).

Users don't think in terms of a character being displayed with both a
foreground and a background - for them, the character *is* its foreground
appearance; the background is, well, background ;-). Figure vs ground: by
definition, the (back)ground is not noticed; it is not thought about. 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.

    (2) could be good, but one needs
    to decide which colors to put in initially.

I didn't "add some initial colors". I was trying to accomodate your
complaint that I had suggested getting rid of them (the Face submenu). I was
agreeing that there is a use for a limited number of them. I combined menus
Face, Foreground Color, and Background Color in one menu, Color.

        Make Background a submenu of Color, since this kind of quick color
        application is generally for foreground only.

        I've shown the basic color choices as a menu here, not as a
        palette. I would rather see Color not as a submenu but as a
        Color... menu item that brings up a tiny palette of, say,
        20 basic colors, with swatches instead of names (but
        tooltips for the names).

    That might be good, but it's nontrivial.  It might need to be written
    in C.  If someone wants to start working on it, please do.

It's trivial if the palette is a separate, popup frame. Don't think menu;
think frame (or window, or buffer, if you prefer). No C, no toolkit, nothing
fancy needed.

Just show a frame (buffer) with 20 faces applied to 20 space characters (or
20 pairs of adjacent space characters, for wider swatches). Each face would
have a different background color. Each such "swatch" would act as a
"button": clicking it would apply the color to the buffer text that was
selected. As I said, I do this now, using 10,000 colors (10,000 faces) for a
general color editor.

        "Other..." would replace today's top-level Display Colors
        item. Like my suggestion for Display Faces, this display
        would be active, so you could click a color to apply it
        to the selected text.

    I have lost you here.

Other... is in the same menu; it lets you access (and apply) additional
colors, besides the 20 shown directly in the mini-palette (or the menu).
Choosing Other... calls (an enhanced version of) `list-colors-display'. Like
the enhanced display of faces, that display of all named colors would be
clickable. You click a color name to apply that color to the text that was
selected in the buffer. IOW, the effect is identical to picking, say, the
red swatch in the mini-palette (or Red in the menu, if there is no
mini-palette): the selected text gets the color whose name you clicked in
the `list-colors-display' (buffer *Colors*).

        If we used a Color... menu item instead of a Color submenu,
        then Other... would be a button on the palette.

    Even more lost.

I described two possibilities: one was menu-oriented (menus only); the other
was palette-oriented. In the latter, the Color submenu would be replaced by
a simple menu item, Color.... When you click that item, the mini-palette (a
buffer) is displayed (instead of a submenu being displayed). In the
mini-palette, there would be an Other... button; that is analogous to the
Other... item in the submenu model. In either model, Other... opens the
*Colors* display, which you can click to apply any named color to the
selected text (see above).

I personally prefer the palette mode (swatches) to the submenu model.

        Face... would replace today's top-level Display Faces item.
        It would do what I described previously - you could click a
        face to apply it to the selected
        text (just as you apply a foreground color).

    As I explained before, the whole list of faces would be
    inconveniently large.

As I explained before, using it would be as quick as, or quicker than,
accessing color names in a long menu - two clicks. You obviously do not
*need* to use Face..., if all you want to do is apply one of the 20 basic
colors to text. Face... is like Other...; it is to faces what Colors >
Other... is to colors.

As I explained, applying a color from Other... could add it automatically to
the mini-palette (or menu) - just as, today, we automatically add a color
that you use to the Foreground Color menu. Then, the next time you want to
use it, you have it directly in the Color... palette or menu.

Similarly, I mentioned, in my first email, the possibility of automatically
adding faces that you've applied, to the Faces menu. That was before my
suggestion to put the emphasis on styles and colors, not faces. I don't
think there is a need for a short-list Faces menu or mini-palette, analogous
to the Colors menu or mini-palette; accessing the list of all faces is OK. I
expect users to apply faces much less often than they apply colors and
styles.

I know you're busy, but please read my email again (perhaps after the
release). The idea is really not that complicated.