facemenu-unlisted-faces

facemenu-unlisted-faces

[Richard Stallman]

This is an item that needs doing for the release:

    ** Update facemenu-unlisted-faces, adding whatever other
    face name prefixes should be in it for good results.

Would someone please do this and ack?
We are getting really close to starting pretesting;
please help move things along.

Re: facemenu-unlisted-faces

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> This is an item that needs doing for the release:
>
>     ** Update facemenu-unlisted-faces, adding whatever other
>     face name prefixes should be in it for good results.
>
> Would someone please do this and ack?
> We are getting really close to starting pretesting;
> please help move things along.

The faces I see in my long-running Emacs session, which were "let
through" by facemenu-unlisted-faces, are:

default
bold
italic
bold-italic
underline
isearch
lazy-highlight
file-name-shadow
query-replace
match
buffer-menu-buffer
tooltip
button
help-argument-name

I don't know what faces ought not to be there.  Probably `tooltip',
`help-argument-name', etc. ought not to be there, but what's the
criterion?

Assuming the facemenu is meant for users to select a face to put into
whatever buffer they are editing (via Edit->Text Properties->Face), I
would argue that the facemenu should be populated by an include list
rather than an exclude list.  I suggest just the following:

bold
bold-italic
default
fixed-pitch
underline

and that's it.

RE: facemenu-unlisted-faces

[Drew Adams]

    I don't know what faces ought not to be there.  Probably `tooltip',
    `help-argument-name', etc. ought not to be there, but what's the
    criterion?

If I read the facemenu.el commentary correctly, the faces that should be
there are faces that users will not be likely to apply to text in a buffer.

    Assuming the facemenu is meant for users to select a face to put into
    whatever buffer they are editing (via Edit->Text Properties->Face), I
    would argue that the facemenu should be populated by an include list
    rather than an exclude list.  I suggest just the following:

    bold bold-italic default fixed-pitch underline

I agree: if users can only choose a face to apply by clicking its name in
the Face submenu, then that submenu should be short. I think, however, that
the Face submenu is pretty useless, whether short or long. I'd suggest
removing it altogether, after the release.

On the other hand, a long list, a la `list-faces-display', can be useful -
it just should not be placed in-line in a menu. We could enable use of
`list-faces-display' to apply a chosen face to the region (what Faces > ...
does today).

Today, the `list-faces-display' list just gives you access to 1) Customizing
the face and 2) the *Faces* description of the face. those two could be
combined in the same mouse click - they both give you info on the face. In
fact, they already are combined, in the sense that *Faces* has a link to
Customize the face.

So, clicking the face name in `list-faces-display' could simply apply that
face to the region (what Faces > ... does today). And clicking the face's
alphabet would show the *Faces* description of the face, with a link to
Customize it.

IOW, my suggestion is to get rid of menu Faces, and let users obtain its
functionality for any face, via a more active `list-faces-display'.

The best interaction, BTW, is that provided by `M-o o': it lets you choose a
face to apply using face-name completion. Like `list-faces-display', no
faces are excluded from that list - if a user wants to apply face
`mode-list' to text in a buffer, s?he can.

Re: facemenu-unlisted-faces

[Richard Stallman]

    I think, however, that
    the Face submenu is pretty useless, whether short or long. I'd suggest
    removing it altogether, after the release.

This is a step towards WYSIWYG editing.  We are going to move forward,
not backward, so please stop suggesting backward steps.

    So, clicking the face name in `list-faces-display' could simply apply that
    face to the region (what Faces > ... does today). And clicking the face's
    alphabet would show the *Faces* description of the face, with a link to
    Customize it.

That could be a good idea, but remember there are lots of faces
in the buffer made by `list-faces-display', so this would not be
a convenient way to select and apply one for editing purposes.

RE: facemenu-unlisted-faces

[Drew Adams]

        I think, however, that
        the Face submenu is pretty useless, whether short or long.
        I'd suggest removing it altogether, after the release.

    This is a step towards WYSIWYG editing.  We are going to move forward,
    not backward, so please stop suggesting backward steps.

I won't argue with you, except to point out that "please stop" implies that
I am continually suggesting steps that you regard as backward. I don't think
that's the case, even from your (backward? forward?) point of view.

Regardless of what your view might be of the direction I'm facing, the
suggestions I've made have in fact generally been in the direction of
WYSIWYG and direct manipulation. My own libraries emphasize this, in
particular regarding faces and colors.

If you want to have simple faces in the Faces menu, then limit the choices
to Bold, Italic, and Underline, as well as perhaps a few simple color
swatches for quickly changing foreground color (forget about dired-this and
*-that). That's what most WYSIWYG menus provide. The number of such "faces"
is usually less than 20, and the menu item for a color is a swatch, not its
name ("Red") - the "menu" appears more as a rudimentary palette than a list
of names. A simple, quick menu for bold, italic, underline, and a few simple
foreground colors would be useful.

Most WYSIWYG UIs also make bold, italic, and underline available as tool-bar
buttons.

Most WYSIWYG UIs also provide some (perhaps not quite so quick) way to apply
an arbitrary color to text. That's what an active list-faces-display could
help do (see next), as could also a more sophisticated color editor.

        So, clicking the face name in `list-faces-display' could
        simply apply that face to the region (what Faces > ...
        does today). And clicking the face's alphabet would show
        the *Faces* description of the face, with a link to
        Customize it.

    That could be a good idea, but remember there are lots of faces
    in the buffer made by `list-faces-display', so this would not be
    a convenient way to select and apply one for editing purposes.

No, it might not be a substitute for a quick way to make text bold, italic,
or underlined. It would serve a different purpose: let you choose and apply
*any* face. Menu item Display Faces should then be rebaptised to some other
name that suggests that you can use it to apply a face.

Actually, even though it lets you do more, accessing an arbitrary face this
way would not necessarily be longer than picking its name out of menu Faces.
The Display Faces menu item is one click. Finding a face in the displayed
list can take a moment, admittedly, but at least you can look for it by
appearance and not just by name as in menu Faces. Picking the face is a
second click. Two clicks total - the same as picking a face name in submenu
Faces. And you have direct access by appearance, vs reading names. I won't
argue that it's always as quick, but it might often be about as quick.

After a user has used list-faces-display to apply a face to text, that face
(and its appearance) could be added to the Faces menu for subsequent quicker
access in that session (assuming that it is in fact quicker). It would then
be on a par with Bold, though farther down the menu.

Re: facemenu-unlisted-faces

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> If you want to have simple faces in the Faces menu, then limit the
> choices to Bold, Italic, and Underline, as well as perhaps a few
> simple color swatches for quickly changing foreground color (forget
> about dired-this and *-that). That's what most WYSIWYG menus
> provide. The number of such "faces" is usually less than 20, and the
> menu item for a color is a swatch, not its name ("Red") - the "menu"
> appears more as a rudimentary palette than a list of names. A
> simple, quick menu for bold, italic, underline, and a few simple
> foreground colors would be useful.

One problem with mere swatches is that a non-trivial part of the male
population (typical programmer's sex) is color-blind in some respect.
If those swatches are used for more than coloring the person's
personal screen (namely if colors may persist), then picking colors
judiciously necessitates seeing their names for such people.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: facemenu-unlisted-faces

[Drew Adams]

    > more as a rudimentary palette than a list of names. A
    > simple, quick menu for bold, italic, underline, and a few simple
    > foreground colors would be useful.

    One problem with mere swatches is that a non-trivial part of the male
    population (typical programmer's sex) is color-blind in some respect.

Yes, about 8% of men and 0.5% of women are in some way "color challenged".

    If those swatches are used for more than coloring the person's
    personal screen (namely if colors may persist), then picking colors
    judiciously necessitates seeing their names for such people.

We're talking about GUI shortcuts here - tool-bar and short-menu access.

Daltonians can cope with that as they do for other UIs that employ color. We
can add tooltips to the swatches. That will serve those with screen readers
too (I don't know if the blind bother creating and editing text with color,
but they might at least want to use bold etc. for emphasis.)

Using the main suggestion I made, someone could apply a face by name (plus
appearance) in the exhaustive face list, and its name (and appearance) would
then be added to the quick-access menu for subsequent use.

There are lots of things in WYSIWYG applications that are not especially
friendly to the blind, color-blind, and people with other accessibility
issues. For accessibility, the important thing is to not rely on things like
color as the *only* way to differentiate something. Accessibility
guidelines, for instance, don't tell you not to use color - they tell you
not to use only color to communicate information. If you provide users
alternative ways to access the same information, there should be no problem.

Let's not throw out the baby with the bath water here. A 20-color "menu" of
swatches in Outlook (since I'm using email now) takes up about 1cm x 4cm.
The equivalent menu with names (colored or not) would take up maybe 3cm x
20cm. And picking out a color by name is much slower than picking it out by,
well, color (for those who see color).

Re: facemenu-unlisted-faces

[Richard Stallman]

    A 20-color "menu" of
    swatches in Outlook (since I'm using email now) takes up about 1cm x 4cm.

The general idea seems good, but isn't that too small?  Each color
must be approx .2 cm squared.  Isn't it slow to put the mouse on such
a small space?

If it were larger, the colors' names could appear too.

RE: facemenu-unlisted-faces

[Drew Adams]

        A 20-color "menu" of
        swatches in Outlook (since I'm using email now) takes up
        about 1cm x 4cm.

    The general idea seems good, but isn't that too small?  Each color
    must be approx .2 cm squared.  Isn't it slow to put the mouse on such
    a small space?

No, I see no problem with it. We could of course make it larger, but I see
no need for that. My point was that swatches save space, and they let you
see colors close together, for comparison.

OK, let me measure now (in Outlook)... The entire palette is 1cm x 4.3 cm,
and each swatch is 0.5cm x 0.5cm. Each swatch is a button 0.5cm x 0.5cm, but
the actual swatch (colored) part of the button is only 0.3cm x 0.3 cm - the
rest is padding (button margin).

I checked in MS Word also - the palette is the same (same size swatches),
but there are 40 colors present, not 20, and there is also a "More
Colors..." button for accessing a general color editor (which I suggested as
"Other...").

    If it were larger, the colors' names could appear too.

The point here is *not* to use the names (but to make them available via
tooltip). Displaying names can be useful for faces (vs colors), and it can
be useful for colors if you have a long list - that's why I made the
suggestions about adapting `list-colors-display' and `list-faces-display'.

With only 20 colors, there is really no need for names. Here are the 20
colors I see in Outlook (they are for foreground only). I held the mouse
over each to see its name in a tooltip:

 Black, Gray, Maroon, Olive, Green, Teal, Navy, Purple
 White, Silver, Red, Yellow, Lime, Aqua, Blue, Fuchsia

I would never have guessed those names, BTW. If I had to name them, I would
have said this:

 Black, Dark Gray, Brown, Olive Green, Dark Green, Dark Cyan,
    Dark Blue, Purple
 White, Light Gray, Red, Yellow, Bright Green, Cyan, Blue,
    Magenta (or Pink)

When you want to make some text pink, you just select it, hit the "A"
tool-bar button, and click the pink swatch in the displayed mini-palette.
You don't have to read color names and think about whether pink corresponds
to "Fuchsia" or "Teal".

Re: facemenu-unlisted-faces

[Richard Stallman]

	If it were larger, the colors' names could appear too.

    The point here is *not* to use the names (but to make them available via
    tooltip).

That makes no sense.  Showing the actual colors is useful; hiding
their names is not useful.

RE: facemenu-unlisted-faces

[Drew Adams]

        The point here is *not* to use the names (but to make them
        available via tooltip).

    That makes no sense.  Showing the actual colors is useful;

Useful for what? Colors *identify themselves*, by their appearance. Why do
you want to read color names? For blind people, tooltips are available, or
they can use the complete list of colors, which provide names.

The quick color-choice menu or palette has only simple colors, whose names
are not important (and can even get in the way, as I demonstrated with
"Fuchsia"). If you need to use precisely the color "blanched almond", then
you use the complete list of colors.

    hiding their names is not useful.

Why not? it makes it easier for you to see the colors (swatches), reduces
clutter and noise, and saves space.

Re: facemenu-unlisted-faces

[Richard Stallman]

	That makes no sense.  Showing the actual colors is useful;

    Useful for what? Colors *identify themselves*, by their appearance.

To know what name to use in other contexts.
To identify a specific shade (not all of us recognize shades well).
For color-blind people.

RE: facemenu-unlisted-faces

[Drew Adams]

    	     That makes no sense.
           Showing the actual colors is useful;

        Useful for what? Colors *identify themselves*, by their
        appearance.

    To know what name to use in other contexts.
    To identify a specific shade (not all of us recognize shades well).
    For color-blind people.

Let's not belabor this. I already spoke to those concerns. A tooltip on the
swatch shows the name - just rest the mouse over it a moment (and listen to
your speech reader).

And, all colors are available (and searchable) by name, via "Other...". And
you can use completion to compose the name. [And, as I said, I think that
(Other...) way of choosing a color will be about as quick, in practice, as
the "quick-access" choice of a color in the main menu.]

Furthermore, any text that has a given color applied can be checked (or
should be able to be checked!) for the name of that color, using menu item
Describe Properties.

Re: facemenu-unlisted-faces

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> If you want to have simple faces in the Faces menu, then limit the
>> choices to Bold, Italic, and Underline, as well as perhaps a few
>> simple color swatches for quickly changing foreground color (forget
>> about dired-this and *-that). That's what most WYSIWYG menus
>> provide. The number of such "faces" is usually less than 20, and the
>> menu item for a color is a swatch, not its name ("Red") - the "menu"
>> appears more as a rudimentary palette than a list of names. A
>> simple, quick menu for bold, italic, underline, and a few simple
>> foreground colors would be useful.

This idea is more relevant for the "Foreground Color" and "Background
Color" submenus of "Text Properties", which currently are populated
only by the entry "Other" (which prompts you to enter a color name).

> One problem with mere swatches is that a non-trivial part of the male
> population (typical programmer's sex) is color-blind in some respect.
> If those swatches are used for more than coloring the person's
> personal screen (namely if colors may persist), then picking colors
> judiciously necessitates seeing their names for such people.

The standard way that graphical programs get round this is to add a
little colored box next to the color name.  However, I don't know of a
simple way to do this valid for all the toolkits Emacs runs on
(e.g. text properties don't show up in GTK menus.)  Probably someone
can look into this after the release.

RE: facemenu-unlisted-faces

[Drew Adams]

    >> A simple, quick menu for bold, italic, underline, and a few simple
    >> foreground colors would be useful.

    This idea is more relevant for the "Foreground Color" and "Background
    Color" submenus of "Text Properties", which currently are populated
    only by the entry "Other" (which prompts you to enter a color name).

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.

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.

Why not combine the three current menus, Faces, Foreground Color, and
Background Color, as well as the current menu items Display Colors and
Display Faces, as follows:

 Text Properties

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

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

We could also choose to provide a different set of basic-color choices for
the background - e.g. pastel highlighters instead of saturated colors. The
sets (foreground, background) of basic-color choices could be determined
automatically, based on the background mode (light, dark), and it could be
user-configurable (use your favorite 20 foreground and background colors).

We could discuss whether there should be a Style submenu or we should just
put Bold, Italic, and Underline in the top-level menu. I'd rather see a
submenu used, but also have a tool-bar button for each style (common in many
GUIs).

"(and so on)" would not be in the menu - I use it here for brevity. Each of
the small set of basic colors would appear explicitly as a menu item: Red,
Green, Blue, Yellow, Magenta, Cyan, Black, White,... We would need about 20
easily recognizable color names.

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). This palette would have a Background checkbox. No
Color menu, no Background menu. We could decide whether checking the
Background box would change the basic-color choices to a set of highlighters
(IMO: yes).

"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. Other... would show a
complete list of all named colors - an extension of the small set of colors
available in the menu/palette individually. Or, it could open a complete
color editor, a la my library palette.el (the concept, not the
implementation).

If we used a Color... menu item instead of a Color submenu, then Other...
would be a button on the palette. The Background checkbox on the palette
would also apply to whatever color you choose using Other... In this case,
the top-level menu would have only three menu items (for the stuff discussed
here): Style, Color..., and Face... - no submenus except Style.

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). This would be the only place
where faces would be chosen as such - the style and color items would apply
text properties, not faces.

Bold, Italic, and Underline (in the Style menu) would be checkbox-toggle
menu items. You could thus combine style attributes (e.g. bold plus italic).
If you clicked Bold for a selection of text that was already bold, then it
would become unbold (and the check mark would go away). This is standard
behavior in many GUIs.

Each style (Bold, Italic, and Underline), would also be available as a
tool-bar button. The pressed/unpressed appearance of each button would
indicate the state of the selected text at all times (e.g. Bold pressed for
bold text).

The mini-palette (20 colors, plus an Other... button) would also be
available via a toolbar button, providing the more typical access (e.g. the
colored `A' button in Word and Outlook).

    > One problem with mere swatches is that a non-trivial part of the male
    > population (typical programmer's sex) is color-blind in some respect.
    > If those swatches are used for more than coloring the person's
    > personal screen (namely if colors may persist), then picking colors
    > judiciously necessitates seeing their names for such people.

    The standard way that graphical programs get round this is to add a
    little colored box next to the color name.  However, I don't know of a
    simple way to do this valid for all the toolkits Emacs runs on
    (e.g. text properties don't show up in GTK menus.)  Probably someone
    can look into this after the release.

A simple way to do this would be to pop open a tiny frame with color
swatches. I do this with my palette code, for instance. I use 10,000 colors,
so 10-20 colors won't be a problem - just use a space character or two with
the swatch color as its background. IOW, don't think "menu", think "palette
buffer" - no toolkit problems and a better UI.

Wrt name vs name+swatch vs swatch, whether in a menu or not:

There is truly no need for color names (except in tooltips, for
accessibility). Swatches (only) are appropriate for this. The point here is
to offer multiple colors in a small space, and let users pick by appearance.
We are not talking about faces here, but colors, and using color names for a
set of 20 colors is silly.

After Waiting for Godot, of course.

Re: facemenu-unlisted-faces

[Richard Stallman]

    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 "fixed pitch", I think that can only be considered as a face.

    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.

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

We certainly don't want them all in one large menu.

     Text Properties

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

I see you agree, because that isn't combining them.

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).  (2) could be good, but one needs
to decide which colors to put in initially.

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

Do others agree that is true?

    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.

    "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.

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

Even more lost.

    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.

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.

Re: facemenu-unlisted-faces

[Richard Stallman]

    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".

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

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

			  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.

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.

Re: facemenu-unlisted-faces

[Richard Stallman]

     - 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).

The "Blue" menu item could be set up to specify red, too.

The crucial point is that that would be an anomalous reprogramming of
Emacs.  Likewise, if a face "blue" specifies red, that is also an
anomalous reprogramming of Emacs.

For simplicity, we can ignore those anomalous possibilities when
designing features like this one.  We can assume that the command
whose name indicates blue really does as its name implies.

    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.

Emacs gives you enough rope to mess up a lot of things.  We don't need
to bulletproof these features against such messes.  We just say "So
don't do that, then."

    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.

I agree, but that point seems to cut equally well in all directions.

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

You presented a choice of face or face attribute, and I said it
can't be considered a face attribute.

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

    Some fonts are bold and some are not, also.

Yes, but there is a face attribute for boldness.
There isn't a face attribute for fixed-pitch-ness.

RE: facemenu-unlisted-faces

[Drew Adams]

         - 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).

    The "Blue" menu item could be set up to specify red, too.

?? (:foreground "Blue") is pretty much a constant. Yes, of course, someone
could sneak in and sabotage the menu. What's the point?

    The crucial point is that that would be an anomalous reprogramming of
    Emacs.  Likewise, if a face "blue" specifies red, that is also an
    anomalous reprogramming of Emacs.

Faces are variables. They are *meant* (designed) to be variables. Text
properties are constants (which you can apply to text variably, of course).
They are *meant* to be constants. Reprogramming of constants, but not
variables, is anomalous behavior.

    For simplicity, we can ignore those anomalous possibilities when
    designing features like this one.  We can assume that the command
    whose name indicates blue really does as its name implies.

Agreed.

The real point is that introducing the added (conceptual) complexity of
"face" is not necessary in this part of the UI. A user need not understand
what a face is to make text bold or red or fixed pitch.

        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.

    Emacs gives you enough rope to mess up a lot of things.  We don't
    need to bulletproof these features against such messes.  We just
    say "So don't do that, then."

Agreed. I was simply explaining my use of "happenstance". A face is, by
design, a variable. Of course we want to discourage people from changing
predefined faces that we regard as constant and upon which the normal
functioning of the UI depends.

I was speaking to the fact that face `fixed-pitch' is a loose (i.e.
happenstance) association between a name that describes an appearance and
the current value of a face (which is a variable). A text (or font or
whatever) property of fixed pitchness or boldness is something constant -
you can apply it variably to any text you like, but the attribute/property
itself will always mean/be the same thing.

        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.

    I agree, but that point seems to cut equally well in all directions.

??

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

    You presented a choice of face or face attribute, and I said it
    can't be considered a face attribute.

I don't recall exactly what I said, and I don't want to take the time to
look it up. My point was that the model to use for the user is that of
applying some constant property that affects appearance to selected text.
Fixed pitchness can be conceived of (by the user & presented as such in the
UI) as such a constant attribute/property/characteristic that can be applied
to text - even if that is not in fact the way the implementation behaves.

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

        Some fonts are bold and some are not, also.

    Yes, but there is a face attribute for boldness.
    There isn't a face attribute for fixed-pitch-ness.

Yes. I wasn't speaking of Emacs face attributes per se, but of the user
thinking in terms of applying a property/style/attribute to some text. How
we do that under the covers is unimportant (unless it invalidates the user's
conceptual model).

My point was that it is possible to have a UI that lets the user think only
in terms of applying boldness and fixed-pitchness to text, without - at that
point - introducing the notion of "face". That's all.

Re: facemenu-unlisted-faces

[Richard Stallman]

	The crucial point is that that would be an anomalous reprogramming of
	Emacs.  Likewise, if a face "blue" specifies red, that is also an
	anomalous reprogramming of Emacs.

    Faces are variables. They are *meant* (designed) to be variables.

They are not all meant to be changed.

RE: facemenu-unlisted-faces

[Drew Adams]

    	The crucial point is that that would be an anomalous reprogramming of
    	Emacs.  Likewise, if a face "blue" specifies red, that is also an
    	anomalous reprogramming of Emacs.

        Faces are variables. They are *meant* (designed) to be variables.

    They are not all meant to be changed.

Perhaps we are miscommunicating. AFAIK, faces are customizable, which means
that they are designed to be customized.

The bold text property will always represent boldness, but just because I
defface a face called my-very-bold-face that has bold as an attribute, that
does not mean that it will always look bold - its appearance can be changed
by program or customization. That's all I meant.

Re: facemenu-unlisted-faces

[Richard Stallman]

    Perhaps we are miscommunicating. AFAIK, faces are customizable, which means
    that they are designed to be customized.

No it doesn't mean that, any more than the existence of a "variable"
means its value is meant to be changed, or the existence of a function
name means that its function definition is meant to be changed.

Almost anything in Emacs can be changed.  But most Emacs facilities do
NOT try to be bulletproof against all changes that someone might make.
It would be counterproductive.  So please forget about arguing that "X
has to be bulletproof against changing Y merely because Y can be
changed."

RE: facemenu-unlisted-faces

[Drew Adams]

        Perhaps we are miscommunicating. AFAIK, faces are
        customizable, which means that they are designed
        to be customized.

    No it doesn't mean that, any more than the existence of a "variable"
    means its value is meant to be changed, or the existence of a function
    name means that its function definition is meant to be changed.

    Almost anything in Emacs can be changed.  But most Emacs facilities do
    NOT try to be bulletproof against all changes that someone might make.
    It would be counterproductive.  So please forget about arguing that "X
    has to be bulletproof against changing Y merely because Y can be
    changed."

I give up.

FWIW - I never argued that anything should be bulletproof or that anything
shouldn't be changeable. My argument was that applying a text property (such
as boldness) to text is conceptually simpler and closer to what newbies are
used to than is applying a face to text. That's all.

You argued that face `fixed-pitch' cannot accomodate the model of applying a
property/attribute/style, and that the user needs to think in terms of
applying a face in this case - that is, the UI needs to treat it as a face,
exceptionally. I argued that we could treat fixed-pitchness in the UI the
same way we treat boldness, and there is no need for users to monkey with
face `fixed-pitch' at this level. It is no different from any other face;
all faces would be available in the faces display, and none (including
`fixed-pitch') would need to be available in the top-level menu.

The discussion about variables vs constants came up because I mentioned that
the face name "fixed-pitch" is an exception to the way most faces are named
(in terms of their use, not their appearance), and there is nothing
*necessarily* fixed-pitch about that face, since it could be changed.
Understanding the concept of "face" includes understanding that a face is
changeable, and that is not true of text properties.

Re: facemenu-unlisted-faces

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Understanding the concept of "face" includes understanding that a face is
> changeable, and that is not true of text properties.

You're apparently using some bizarro definition of the term "text
property", because the text properties most of us use are indeed
changeable.

Maybe you're talking about the practice of using face-attribute lists
instead of named faces??

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

RE: facemenu-unlisted-faces

[Drew Adams]

    > Understanding the concept of "face" includes understanding
    > that a face is changeable, and that is not true of text properties.

    You're apparently using some bizarro definition of the term "text
    property", because the text properties most of us use are indeed
    changeable.

    Maybe you're talking about the practice of using face-attribute lists
    instead of named faces??

Sorry I'm not getting this across. I'll try one more time. It's really not
that important, so hit delete if you're tired of this.

I can use the number 4 or not use it, but it remains the number 4 - it is
not changeable. I can apply  the :bold attribute to text or not, but it
remains the unchangeable :bold attribute; if applied, it always imposes
boldness. That is different from use of a face whose name happens to be
`bold', even if the face looks bold. Whether applied to text or not, the
`bold' face is not a constant, and its name "bold" doesn't necessarily stand
for how it looks.

I tried to say that I was not speaking necessarily of Emacs text properties,
or face attributes, or font properties, or styles, but of all of those, on
the one hand, and faces on the other. And I was not making a difference in
terms of implementation but in terms of user (conceptual) model.

Consider some text that has a :foreground face attribute with a value of
"Red" applied to it as a text property. The value of :foreground that is
applied to that particular text can certainly be changed (e.g. to "Green"),
and the :foreground attribute can be removed from the text altogether. But
the color "Red" can't be changed; it's a constant. It's not just a name
associated with the color, whose association can be changed. And the meaning
of :foreground cannot be changed; it always means the foreground color,
regardless of its value. Likewise, for face attribute :underline: it can be
applied to text or removed, but it always means underlining. Likewise :bold
always means boldness.

On the other hand, a face that happens to be named `underline', and that
has, right now, an appearance of underlining, is not such a constant.
Applying the attribute :underline will always underline, but applying the
face `underline' will not (not necessarily). The definition and appearance
of a face named `bold' can change; the definition and appearance of
attribute :bold cannot.

Users unused to Emacs don't know or care about faces. They can and will
eventually use them, and that's good. But they don't _need_ to understand
the notion of a face to be able to apply constant
"properties"/"styles"/"attributes" (however such things are defined) to
text. That's the model to use for the Text Properties menu, with the sole
exception of `Face...', where Emacs faces are applied.

Let users think simply in terms of applying boldness, underlining, redness,
and so on, where each of these properties (again, however it might be
implemented) is thought of as as constant.

To my mind, we can treat fixed pitchness the same way. Even if "applying"
fixed pitchness really means changing the font family, or even if it really
means applying a `fixed-pitch' face, or whatever, things should work simply
enough that the user need not be aware of that, that s?he can think of
applying fixed pitchness the same way s?he thinks of applying underlining.
IOW, think of it as a constant property that you are applying to the text.

Finally, I don't really care about fixed pitchness. I don't care whether we
provide it along with Bold and the others, as if it were a constant property
you can paint text with (even if it is not, in terms of implementation), or
whether we force users to use face `fixed-pitch' and be aware that they are
doing that. I simply meant to point out that what Richard said was not
necessarily true:

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

Fixed pitch _can_ be treated like any of the other constant "properties",
_if we want_. If you prefer to treat it as an exception, as the only face in
the menu (aside from face access via `Faces...'), so be it. My only point
about it was that we do not _have_ to present fixed pitchness to the user as
a face. (Personally, I'd prefer to remove it from the Text Properties menu,
and treat it only in the font menu, as a font-family change - which it is.)

Re: facemenu-unlisted-faces

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Fixed pitch _can_ be treated like any of the other constant "properties",
> _if we want_.

It's not just an arbitrary choice -- "fixed pitchedness" is not
typically a composable property of fonts like boldness/size/family/etc.

It would be _nice_ if it were -- it would be very convenient to be able
to say `give me a fixed pitch font that otherwise "matches" the
underlying font', for instance; but as far as I can see, that would
probably be hard to implement, because it's not supported by the
underlying font mechanisms and designs.

[However, I also see no evidence that users think of it that way.]

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

RE: facemenu-unlisted-faces

[Drew Adams]

    > Fixed pitch _can_ be treated like any of the other constant
    > "properties", _if we want_.

    It's not just an arbitrary choice -- "fixed pitchedness" is not
    typically a composable property of fonts like boldness/size/family/etc.

Family? I'm not sure that family is composable (face `fixed-pitch' is, after
all, just a face with only :font-family defined). But I agree with the
general idea.

    It would be _nice_ if it were -- it would be very convenient to be able
    to say `give me a fixed pitch font that otherwise "matches" the
    underlying font', for instance; but as far as I can see, that would
    probably be hard to implement, because it's not supported by the
    underlying font mechanisms and designs.
    [However, I also see no evidence that users think of it that way.]

I do agree 100%, and I think I stated that. I proposed, for precisely that
reason, that we remove fixed pitchness from the Text Properties menu
altogether, and treat it like the font property it is.

My point was this:

 - `fixed-pitch' would be available as a face in the Text
   Properties menu anyway, via the Faces... item. That item
   would display the list of all faces, including
   `fixed-pitch', and let you click to apply any of them
   to selected text.

 - _If_ someone (e.g. RMS) insisted that fixed pitchness also
   be available in the Text Properties menu at the same level
   as the various face attributes (Bold etc.), then that
   _could_ be done. We could make it so that the user thought
   s?he were simply applying an attribute/property of fixed
   pitchness - as opposed to applying face `fixed-pitch'.

In the latter case, yes, I agree that fixed pitchness, even if we passed it
off as a (pseudo) text property, so users could think of it that way, would
be different from the others, in that it is not composable (good way to put
it; thanks). Applying fixed pitchness might wipe out (in appearance) other
attributes a user had previously applied.

Because of this difference and source of possible confusion, I proposed that
we not put fixed pitchness on the Text Properties menu (except as a face
like any other), and, instead, treat it like the font property it is. IIUC,
fixed pitchness is properly understood as picking a fixed-pitch font.

Face `fixed-pitch' is simply a face whose only defined attribute is
:font-family (Courier). Currently, users can only apply that particular
fixed-pitch face, so they can only get the particular fixed-pitch font
Courier this way. So, there would be no loss of generality if we treated
fixed pitchness as :font-family "Courier". (Replace "Courier" with another
fixed-pitch font if the :font-family value is determined dynamically, based
on available fonts. It is constant for any given installation.)

In sum, wrt how we treat fixed pitchness, these are my preferences, in
descending order:

1. Remove it from the Text Properties menu altogether (except as a face in
Faces...). Let/make users change font to get a fixed-pitch font. Changing
font is not in the Text Properties menu, in general, and that's TRT.

2. Treat it as a (pseudo) text property, letting users "apply" it as they
apply Bold. This would apply attribute :font-family with a value of
"Courier" (or whatever). This might also require removal of some other text
attributes (e.g. :bold), if the installed Courier fonts did not support
them. Users would be told in the doc that this represents a change of font
family. A message could warn users that other text properties have been
removed (or will be removed) when this is applied.

3. Do what Richard suggested: Keep `fixed-pitch' as the only face in the top
level of the Text Properties menu. I assume he meant that it would appear
along with Bold etc., but the user would be applying the _face_ when s?he
chooses Fixed Pitch.

I prefer #1 because it is simpler and more correct. The user's conceptual
model is of applying styles and colors, and in #1 these map perfectly to
(composable) font attributes. The conceptual model fits the implementation,
which is especially important for Emacs users, because they can and do
drill, dig, and tweak below the surface.

I prefer #2 over #3 because it is simpler for the user. The user's model is
of applying styles and colors, and it is not that aberrant to treat font
family as a kind of "style". IOW, the user could think in this way - the
user's mental model would be simple and coherent, even if it conflicted (in
the case of fixed pitch) with what the implementation is.

I can live with #3. I really don't care much about this, in spite of all the
spilt ink.

Re: facemenu-unlisted-faces

[Robert J. Chassell]

    I can use the number 4 or not use it, but it remains the number 4 - it is
    not changeable. I can apply  the :bold attribute to text or not, but it
    remains the unchangeable :bold attribute; ...

I don't understand you.  The displayed numerical symbol can be set to
any number but few want to set that variable to a value that humans do
not expect.  Similarly, it looks to me that in ...emacs/lisp/faces.el
`:bold' is set to `Face.AttributeBold' although not with a setq, but
in a more complex manner.  (Maybe numbers are not set with setq either
-- I have not looked.)

A `user (conceptual) model' that presumes a `constant' is wrong.  The
user's conceptual model should include the notion that `:bold' is set
to a value that humans generally expect, but it can be something else.
On my display, I set bold to be a kind of red since the heavy weight
of a more conventional bold looks bad.  Naturally, almost no one else
expects `bold' to be displayed as a `normal' weighted character.

You can change anything in a `universal informational machine' (which
is how I have heard computers described).  It is a major mistake to
think of any characteristic from such a universal machine as
`constant'.  Moreover, the machine does not know what human meanings
are attached to the bits it transforms.  As computers become more and
more important in human lives, the danger of mistaking what they can
do becomes more and more dangerous.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: facemenu-unlisted-faces

[Drew Adams]

        I can use the number 4 or not use it, but it remains the
        number 4 - it is not changeable. I can apply  the :bold
        attribute to text or not, but it remains the unchangeable
        :bold attribute; ...

    I don't understand you.  The displayed numerical symbol can be set to
    any number but few want to set that variable to a value that humans do
    not expect.  Similarly, it looks to me that in ...emacs/lisp/faces.el
    `:bold' is set to `Face.AttributeBold' although not with a setq, but
    in a more complex manner.  (Maybe numbers are not set with setq either
    -- I have not looked.)

    A `user (conceptual) model' that presumes a `constant' is wrong.  The
    user's conceptual model should include the notion that `:bold' is set
    to a value that humans generally expect, but it can be something else.
    On my display, I set bold to be a kind of red since the heavy weight
    of a more conventional bold looks bad.  Naturally, almost no one else
    expects `bold' to be displayed as a `normal' weighted character.

    You can change anything in a `universal informational machine' (which
    is how I have heard computers described).  It is a major mistake to
    think of any characteristic from such a universal machine as
    `constant'.  Moreover, the machine does not know what human meanings
    are attached to the bits it transforms.  As computers become more and
    more important in human lives, the danger of mistaking what they can
    do becomes more and more dangerous.

I really didn't intend to get into a discussion of the meaning of levels of
abstraction or the nature of Turing machines and computation. That shouldn't
be necessary to follow my argument. Yes, things are connected in the
universe. Yes, you can drill down to any level you like (maybe) - or up
(maybe). Yes, seemingly nothing is immutable except change itself. Dialectic
of nature; dialectic of ideas. Powers of ten; we are the world. You never
step into the same river twice. We are our environments; our bodies are
replaced every 7 (?) years. Each electron can be thought of as spread
throughout everything. My foot is the same color as the sand; it is the
sand. Dataflow, from garden to me to plumbing to garden.

Yes, a numeral is not a number. And yes, (nearly) any location in a machine
is a variable, and, yes, that includes lots of things one might normally
think of as relatively constant. Even hardware can be programmed, and cosmic
rays are Fortune's envoys.

I was not addressing this level of detail.

At the (usual) Emacs user level, change involves either Lisp (e.g. setq in
.emacs) or Customize. Users think in those terms. Things such as the (in
reality variable) mapping from :bold to displayed boldness are not part of a
user's conceptual model of Emacs behavior. An Emacs user, especially a
newbie, will expect and find that mapping to be constant.

The mapping from face name to appearance, however, is something that Emacs
users normally think of as variable. Why? Because faces are customizable -
users are invited to change the name-appearance mapping. Invited? Yes, in
the same sense that they are invited to change a variable's value or a
function's definition (as Richard pointed out). Does that mean that users
are _encouraged_ to change everything that can easily be changed? Debatable.
Let's say "no". The invitation and possibility are nevertheless there, even
if there is no encouragement.

The point is that some things are easily changed and others are less easily
changed. Things that can be customized are the easiest of all to change,
and, yes, in a sense we invite users to change them, by virtue of making
them customizable. A defvar is less of an invitation to change a variable
than a defcustom, and a defconst is less an invitation than a defvar. There
are degrees of invitation. Some degrees of non-invitation are only
conventional (please don't change a defconst value); others are enforced to
some degree.

Though every machine address invites change by the bit twiddler, there is a
difference in degree, or abstraction level here. And that difference in
degree makes a (perceived) qualitative difference. Unless you resort to what
Richard appropriately termed "anomalous" behavior, some things can
generally, normally, sensibly be considered constants in Emacs, for average,
everyday use. Other things are advertised as open to user modification and
customization. Face attribute :bold is such a "constant"; face
`dired-flagged' is such a variable.

What about face `bold'? Richard would argue that changing its appearance
would be anomalous - presumably because its name suggests a particular
appearance. I'd argue that changing its appearance is probably not what most
people would or should want to do, but it's not anomalous, because a face is
intended to be customized. I'd even argue that it might not be such a good
idea that we _have_ predefined faces that are named for their appearance and
expect users not to modify them. Perhaps a notion and mechanism of "constant
face" would be useful - I don't know. For now, I look at faces `bold' and
`dired-flagged' as the same species of critter. I personally won't be
tempted to redefine the `bold' face (quoique...), but I can imagine that
some application might do that, and I wouldn't be too shocked by that. Call
me "anomalous" or "anomaly lover". I lay the blame at naming a face after a
particular appearance - that's inviting trouble.

Another thing about a variable is that it acts like a slide projector: paint
the slide, and the projected image changes. If you have 8 zillion projected
images, they all change. If you change the appearance of face `bold', then
all text with that face changes appearance. If you like, all "bold" text
(that is, all that has face `bold') can become red and unbold.

Assuming that attribute :bold remains constant (in the user's usual world),
s?he must remove :bold from text that has it applied, then choose and use a
different attribute, to change the appearance of the text. S?he cannot
(easily) redefine the appearance of attribute :bold, so s?he must apply a
different attribute to a particular piece of text to change its appearance.

Now, you might be right that the appearance of :bold itself can be changed
through XResources (on X Window). That hadn't occurred to me, frankly. If
so, that's still (to me) at a different level than changing the value of a
face's properties. The Emacs newbie will be able to think of attribute :bold
as constant, once s?he's inside Emacs. S?he will, on the contrary, learn
that Emacs faces are things that can be customized. That's really all I
meant.

Watching the river flow...

Re: facemenu-unlisted-faces

[Robert J. Chassell]

   I really didn't intend to get into a discussion of the meaning of
   levels of abstraction or the nature of Turing machines and
   computation.

This discussion is very practical.  Non-universal informational
machines do not convert all the bit patterns presented them.  They
only convert some.

Some people aim to ban the sale of universal informational machines
and to replace them with non-universal informational machines -- and
to disguise that ban so many people are not aware.  (The substitution
is called `treacherous' by many, but `trusted' by financial
beneficiaries of the action since they can `trust' that their machines
will not do what the machines' owners expect and desire.  Financial
beneficiaries will, if the substitution occurs, obtain resources from
buyers that they would not obtain in a competitive market.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: facemenu-unlisted-faces

[Richard Stallman]

    I can use the number 4 or not use it, but it remains the number 4 - it is
    not changeable. I can apply  the :bold attribute to text or not, but it
    remains the unchangeable :bold attribute; if applied, it always imposes
    boldness. That is different from use of a face whose name happens to be
    `bold', even if the face looks bold. Whether applied to text or not, the
    `bold' face is not a constant, and its name "bold" doesn't necessarily stand
    for how it looks.

I see your point now.  However, the point is not a strong one, because
it would be perverse to define the face `bold' to do anything other than
make the text bold.

Anyway, we don't need to discuss these subtleties in the text in the
menu.

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

    Fixed pitch _can_ be treated like any of the other constant "properties",
    _if we want_.

No, it can't be done.  I think you don't understand the problem.

RE: facemenu-unlisted-faces

[Drew Adams]

        I can use the number 4 or not use it, but it remains the
        number 4 - it is not changeable. I can apply the :bold
        attribute to text or not, but it remains the unchangeable
        :bold attribute; if applied, it always imposes boldness.
        That is different from use of a face whose name happens
        to be `bold', even if the face looks bold. Whether applied
        to text or not, the `bold' face is not a constant, and its
        name "bold" doesn't necessarily stand for how it looks.

    I see your point now.  However, the point is not a strong one, because
    it would be perverse to define the face `bold' to do anything other than
    make the text bold.

Yes.

    Anyway, we don't need to discuss these subtleties in the text in the
    menu.

Agreed. How we actually change the appearance of the text to fixed pitch is
pretty unimportant. What's important here is the user's view of what goes
on. I want to make sure that whatever we do here lets the user _think_ in
terms of simply applying a "property"/"style"/"attribute" to text, and
doesn't force understanding of faces at this point.

My point was in response to your statement (quoted below) about the
necessity to consider fixed pitch as a face. The _user_ need not consider it
a face when s?he chooses Fixed Pitch in the menu. We should not do anything
to point out that a face is being used (if it is in fact used, instead of
simply using text property :font-family "Courier" directly - see below).

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

        Fixed pitch _can_ be treated like any of the other constant
        "properties", _if we want_.

    No, it can't be done.  I think you don't understand the problem.

Maybe. What's wrong with simply adding :font-family "Courier" as a text
property? If there are then conflicts with other face attributes applied to
the same text, then we can either 1) change the font (family) for that text
anyway, and remove any other, conflicting properties that were applied to
it, or 2) tell the user that fixed pitchness is incompatible (given the
current set of fonts) with the existing font (family) and text properties
used for that text (i.e. punt).

Face `fixed-pitch' just defines the :font-family as Courier - it has no
other face attributes. What's the difference in effect between setting
:font-family to Courier by changing to face `fixed-pitch', on the one hand,
and setting :font-family to Courier directly (as a text property), on the
other hand?

IOW, why can't we use a text property here? Yes, it might not be composable
with other properties that have been applied, but the same issue arises when
we use face `fixed-pitch', no?

Re: facemenu-unlisted-faces

[Richard Stallman]

    I argued that we could treat fixed-pitchness in the UI the
    same way we treat boldness, and there is no need for users to monkey with
    face `fixed-pitch' at this level.

It would be a nice interface, but we can't make it work.  There is a
rule for how to take a font name and get the corresponding bold font.
There is no such rule for finding a fixed-width equivalent.
All we can do is offer ONE fixed-width font.

RE: facemenu-unlisted-faces

[Drew Adams]

        I argued that we could treat fixed-pitchness in the UI the
        same way we treat boldness, and there is no need for users
        to monkey with face `fixed-pitch' at this level.

    It would be a nice interface, but we can't make it work.  There is a
    rule for how to take a font name and get the corresponding bold font.
    There is no such rule for finding a fixed-width equivalent.
    All we can do is offer ONE fixed-width font.

Right, but we need not do that via a face. We could simply add face
attribute :font-family "Courier" (or whatever) to the text that the user
selects.

Again, to avoid more misunderstanding, my personal preference is that we not
include fixed pitchness at the top level of menu Text Properties at all. It
is enough that we make fixed pitchness available in these two ways:

 - by changing the font, using the font menu
 - by applying face `fixed-pitch', using the Face... item,
   which would open (an active version of) the faces list

Re: facemenu-unlisted-faces

[Sascha Wilde]

"Drew Adams" <drew.adams@oracle.com> wrote:

I haven't read the whole thread, so please forgive me if what I'm
going to write is redundant...

[...]
> FWIW - I never argued that anything should be bulletproof or that anything
> shouldn't be changeable. My argument was that applying a text property (such
> as boldness) to text is conceptually simpler and closer to what newbies are
> used to than is applying a face to text. That's all.

I think I'm getting your point and I think you are right, that that's
the way many (most?) people do WYSIWYG text formatting these days.
But I also think, that this is the wrong way to do it, and that we
shouldn't encourage it in any way.

Edited text should be marked up semantically, not by means of concrete
visual properties.

This is especially important with electronic text, where you will
never know about the special properties of the medium the recipient
will use when he reads it:  He might use an X-Terminal (with high
resolution, colors, arbitrary fonts), a Text terminal (which might
only know about bold and one font), a printout, or he might be even
blind, using a speech synthesizer...

Users should rather learn to use a semantically named face like
"subtitle" or "emphasized" from the very start than to mark text as
"bold" or "italic".

These concepts ain't new, they are well known for a long time, but I
think it's a big obstacle, that most existing text processing systems
(let them be WYSIWYG "office" programs or markup languages like HTML)
make it too easy for the user to ignore them.

just my 2¢
sascha
-- 
Sascha Wilde
We're Germans and we use Unix. That's a combination of two 
demographic groups known to have no sense of humour whatsoever.
  -- Hanno Mueller in de.comp.os.unix.programming

Re: facemenu-unlisted-faces

[tomas]

[-- Attachment #1.1: Type: text/plain, Size: 1236 bytes --]

On Thu, Jul 13, 2006 at 10:14:17AM +0200, Sascha Wilde wrote:
> "Drew Adams" <drew.adams@oracle.com> wrote:
> 
> I haven't read the whole thread, so please forgive me if what I'm
> going to write is redundant...
> 
> [...]
> > FWIW - I never argued that anything should be bulletproof or that anything
> > shouldn't be changeable. My argument was that applying a text property (such
> > as boldness) to text is conceptually simpler and closer to what newbies are
> > used to than is applying a face to text. That's all.
> 
> I think I'm getting your point and I think you are right, that that's
> the way many (most?) people do WYSIWYG text formatting these days.
> But I also think, that this is the wrong way to do it, and that we
> shouldn't encourage it in any way.
> 
> Edited text should be marked up semantically, not by means of concrete
> visual properties.

[further arguments towards this elided]

FWIW, modern text programs (yes, even the one with the "W" on its name)
all try to coax the user into a more semantical markup. So yes, I think
it makes sense to try to seduce users into that way of thinking. Making
"visual markup" *the* obvious choice seems to be the wrong way.

regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: facemenu-unlisted-faces

[Robert J. Chassell]

Sascha Wilde wrote

   Edited text should be marked up semantically, not by means of
   concrete visual properties.

Yes.  Also, for at least twenty years, WYSIWYG has meant producing at
least two output formats from the same input.   Nowadays -- that is to
say, for more than a decade -- it means WYSAH, `what you see and hear ...'

Although currently a Texinfo file can be converted directly to seven
output formats, in practice, only three are needed:

  * Info for efficient on-line reading and hearing,

  * HTML for high resolution but less efficient on-line reading, and.

  * DVI, for off-line printing, which can be viewed on-line
    inefficiently.

(You can also directly produce plain text, PDF, DocBook, and XML with
a Texinfo DTD and indirectly produce PostScript, RTF, and LaTeX, plus
others; but the three I mention tell us a great deal.)

Thus, WYSAHIWYG text formatting needs to show visually the three
output formats and enable you to listen as well as see one of them.
(The eyes' free format not only helps the permanently blind, it is
becoming more and more important for people, like other car drivers,
who become situationally blind if they take their eyes off the road,
which we do not wish.)

(Texinfo is not the only input format from which it is easy to produce
multiple output formats.  DebianDoc does the same.  It is one of the
XML formats.)

As a practical matter, everything Drew Adams discusses must work with
these output formats that come from a single input.  To do anything
else is to show incompetence.  It is not easy.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: facemenu-unlisted-faces

[Drew Adams]

Sasha writes:

    > FWIW - I never argued that anything should be bulletproof or
    > that anything shouldn't be changeable. My argument was that
    > applying a text property (such as boldness) to text is
    > conceptually simpler and closer to what newbies are
    > used to than is applying a face to text. That's all.

    I think I'm getting your point and I think you are right, that that's
    the way many (most?) people do WYSIWYG text formatting these days.
    But I also think, that this is the wrong way to do it, and that we
    shouldn't encourage it in any way.

    Edited text should be marked up semantically, not by means of concrete
    visual properties.

    This is especially important with electronic text, where you will
    never know about the special properties of the medium the recipient
    will use when he reads it:  He might use an X-Terminal (with high
    resolution, colors, arbitrary fonts), a Text terminal (which might
    only know about bold and one font), a printout, or he might be even
    blind, using a speech synthesizer...

    Users should rather learn to use a semantically named face like
    "subtitle" or "emphasized" from the very start than to mark text as
    "bold" or "italic".

    These concepts ain't new, they are well known for a long time, but I
    think it's a big obstacle, that most existing text processing systems
    (let them be WYSIWYG "office" programs or markup languages like HTML)
    make it too easy for the user to ignore them.

Tomas continues in the same vein:

    FWIW, modern text programs (yes, even the one with the "W" on its name)
    all try to coax the user into a more semantical markup. So yes, I think
    it makes sense to try to seduce users into that way of thinking. Making
    "visual markup" *the* obvious choice seems to be the wrong way.

You both bring up a different ball of wax. I agree with you (and with TeX
and Framemaker and everyone else) - this is the Emphasis vs Bold discussion.

The current discussion, however, takes as a given that the aim of these menu
items is to provide simple, constant changes to text appearance, without
regard to meaning. I believe that is RMS's position and the raison d'etre
for these menu items. He's after WYSIWYG here, where the WYS and the WYG are
within Emacs buffers (and possibly PostScript form and some other forms).
"Underline" means underline, purely and simply. A speech reader will convey
that using the word "underline", for whatever that information might be
worth.

Faces are the closest mechanism Emacs has to providing (the equivalent of)
more semantics-based markup. And I have no objection to encouraging the use
of faces, especially for that purpose - quite the contrary.

To the extent that we might also want to provide a quick-and-dirty way to
make Emacs text Bold (vs Emphasis), however, that quick-and-dirty mechanism
should probably avoid use of faces for the most part - or at least the two
should be kept separate in the UI.

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.

Re: facemenu-unlisted-faces

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> 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.

"bold", so far as I know, exists mainly for historical reasons.

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').

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

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.

Re: facemenu-unlisted-faces

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> 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.

That doesn't make the least bit of sense -- 90% of the _reason_ for
having a face like `fixed-pitch' is so that the user can change it!

There are various place in emacs that want a fixed-pitch font: by
inheriting from `fixed-pitch', there's no need for the user to customize
all those faces if he wants to change which fixed-pitch font gets used
in general; he can just customize `fixed-pitch'.

A bit of documentation saying "please make sure this face uses a
fixed-pitch font" would be OK, but it seems rather redundant given the
name of the face...

-Miles
-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

RE: facemenu-unlisted-faces

[Drew Adams]

    > 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.

    That doesn't make the least bit of sense -- 90% of the _reason_ for
    having a face like `fixed-pitch' is so that the user can change it!

In a very narrow way (see below). 99.99% of the definition of this face is
*not* intended to be changed by users or code.

    There are various place in emacs that want a fixed-pitch font: by
    inheriting from `fixed-pitch', there's no need for the user to customize
    all those faces if he wants to change which fixed-pitch font gets used
    in general; he can just customize `fixed-pitch'.

I already mentioned the advantage of inheritance from `fixed-pitch'. That's
part of the "argument for its existence as a face". The same advantage is
present, however, if you inherit from a constant face.

Anyway, you raise a good point, even if it is a nuance. Face `fixed-pitch'
is a bit different from faces such as `bold'. In the case of `fixed-pitch',
the intention is not that the face definition (and its appearance) remain
100% constant, but that it remain constant *except* for the :font-family
attribute, and for the :font-family, the intention is that only a
fixed-pitch family be allowed. IOW, you can substitute a different
fixed-pitch font family for Courier, but that's the only way you're supposed
to change the definition of `fixed-pitch'. It's intended to be a very
constant face, but there is a tiny exception.

We're far from being able to specify fine-grained constraints like that,
alas. Which do you think is more important, 1) the fact that the face is
(intended to be) essentially constant (all attributes except :font-family,
and even that is restricted), or 2) the fact that some variability is
allowed? Would you toss it in the `dired-flagged' camp or the `bold' (face)
camp - `defface' or `defconst-face'?

I'd say, given the lack of a mechanism to precisely state and control the
intention, that the best solution is to use an analog of `defconst', and to
express the particular exceptions (your nuance) in the doc string.

There is a world of difference between the intention behind `fixed-pitch'
and the intention behind `dired-flagged'. There is less difference between
face `fixed-pitch and a face such as `bold' that is intended to remain 100%
constant. `fixed-pitch' is a face whose meaning, like that of face `bold',
is based on its appearance, not on its use. Its appearance is (intended to
be) essentially constant.

Re: facemenu-unlisted-faces

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> IOW, you can substitute a different fixed-pitch font family for
> Courier, but that's the only way you're supposed to change the
> definition of `fixed-pitch'. It's intended to be a very constant face,
> but there is a tiny exception.

That's not good enough.  It's pretty common that you also want to change
other attributes -- for instance, the height might need tweaking to make
the particular family you chose mesh well with other faces (this is a
very common occurance).  Similarly, the user might wish to force the face
to bold because the font in question is too light compared to the other
fonts they use.

Frankly I don't know why you seem intent on pushing this point; there
seems little to be gained with a "define-constant-face", even if it
allowed fine-grained specifications of "constantness".  If a user wants
to change something that's not normally changed, well ... so what?  He
probably has his reasons.  Some people despise bold fonts, and would
rather change the `bold' face to use italic.  Why not let them?  Emacs
won't crash.

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: facemenu-unlisted-faces

[Richard Stallman]

    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,

It would be easy to add such a mapping to ps-print if it doesn't have
that feature already.  (Does it?)  That is the only Emacs feature which
can output to "different media".

		     2) the ability to constrain the context of application of a
    given face,

I see no need for that.

		and 3) the ability to define and add new face attributes
    (possibly unrelated to appearance).

That seems like creeping featurism, and is not needed for semantic
markup.

I see no need for "constant" faces.  If you don't want to change one,
don't.

    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.

I would not object to that, if it would solve a real problem.  I don't
want the complexity if the problem it would solve is purely
theoretical.  So far no evidence has been presented that it is real.

RE: facemenu-unlisted-faces

[Drew Adams]

        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,

    It would be easy to add such a mapping to ps-print if it doesn't have
    that feature already.  (Does it?)  That is the only Emacs feature which
    can output to "different media".

        2) the ability to constrain the context of application of a
        given face,

    I see no need for that.

    	  and 3) the ability to define and add new face attributes
        (possibly unrelated to appearance).

    That seems like creeping featurism, and is not needed for semantic
    markup.

I was thinking of the possibility of users adding their own face attributes,
for whatever purposes. I don't know if that would be difficult to handle
(implement).

It is very convenient, for example, that you can add any frame parameters
you want, and use them however you want in your own code. It would be useful
to be able to do the same with face attributes, but I don't know if that
would be difficult to implement (e.g. if existing code counts on a fixed set
of attributes).

    I see no need for "constant" faces.  If you don't want to change one,
    don't.

        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.

    I would not object to that, if it would solve a real problem.  I don't
    want the complexity if the problem it would solve is purely
    theoretical.  So far no evidence has been presented that it is real.

Re: facemenu-unlisted-faces

[Richard Stallman]

    I was thinking of the possibility of users adding their own face attributes,
    for whatever purposes. I don't know if that would be difficult to handle
    (implement).

I have a policy of rejecting proposals to add features when the only
argument in favor is that they make sense and conceivably _might_ be
useful.

Unless I see that they really are useful, I would rather not let them
increase the complexity of Emacs.

Re: facemenu-unlisted-faces

[Richard Stallman]

	    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.

Your initial words were quite misleading.

RE: facemenu-unlisted-faces

[Drew Adams]

    	    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.
    
    Your initial words were quite misleading.

Sorry. Try to take in the whole thing. 

Re: facemenu-unlisted-faces

[Richard Stallman]

    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.

    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.

I agree, that would be an improvement.

	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.

    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.

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

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.

RE: facemenu-unlisted-faces

[Drew Adams]

    From: Drew Adams Sent: Saturday, July 01, 2006 8:17 PM
    Subject: RE: facemenu-unlisted-faces

    We could enable use of `list-faces-display' to apply a chosen
    face to the region (what Faces > ... does today).

    Today, the `list-faces-display' list just gives you access to
    1) Customizing the face and 2) the *Faces* description of the
    face. those two could be combined in the same mouse click -
    they both give you info on the face. In fact, they already are
    combined, in the sense that *Faces* has a link to Customize the
    face.

    So, clicking the face name in `list-faces-display' could simply
    apply that face to the region (what Faces > ... does today).
    And clicking the face's alphabet would show the *Faces*
    description of the face, with a link to Customize it.

    IOW, my suggestion is to get rid of menu Faces, and let users
    obtain its functionality for any face, via a more active
    `list-faces-display'.

    The best interaction, BTW, is that provided by `M-o o': it lets
    you choose a face to apply using face-name completion. Like
    `list-faces-display', no faces are excluded from that list -
    if a user wants to apply face `mode-list' to text in a buffer,
    s?he can.

If anyone is interested to try it, to see what it would be like, I have an
implementation here: http://www.emacswiki.org/cgi-bin/wiki/facemenu%2b.el.
To try it, do this first:

1) (require 'facemenu)
2) (require 'help-mode)
3) Eval just the last sexp before the `provide':
   (when (>= emacs-major-version...)

Then, in a buffer with no font-locking:

1) Optionally select a region

2) `M-o o'

3) Click a face sample (alphabet) to apply that face to the region (or to
newly entered text, depending on whether the region is active and
non-empty).

Again, the advantage of this is that you can see what the face looks like
before you apply it: just choose the face by *appearance* (WYSIWYG) - you
can ignore the face name altogether.

If you use a prefix arg, then you are prompted for the face name, instead of
being shown the *Faces* display. So, `M-o o' lets you apply a face by name
(with completion) or by appearance.

Changes wrt what I suggested originally (above):

1. I switched the two links: clicking the face name gives you info on the
face (including the link to customize), and clicking the face sample applies
the face to the region (or to newly entered chars).

2. I didn't get rid of the Faces menu. You can access the new behavior using
either menu item Faces > Other... or `M-o o'.

Re: facemenu-unlisted-faces

[Richard Stallman]

    The faces I see in my long-running Emacs session, which were "let
    through" by facemenu-unlisted-faces, are:

    default
    bold
    italic
    bold-italic
    underline
    isearch
    lazy-highlight
    file-name-shadow
    query-replace
    match
    buffer-menu-buffer
    tooltip
    button
    help-argument-name

    I don't know what faces ought not to be there.

The ones that are for specific software uses should not be in the
list.  They are isearch, lazy-highlight, file-name-shadow,
query-replace, match, buffer-menu-buffer, tooltip, help-argument-name.

Probably button should also be excluded.

    Assuming the facemenu is meant for users to select a face to put into
    whatever buffer they are editing (via Edit->Text Properties->Face), I
    would argue that the facemenu should be populated by an include list
    rather than an exclude list.  I suggest just the following:

Yes, I agree that would be better.  Nowadays, Emacs has a lot more
faces than in the past, and nearly all of them need to be excluded.

Would you like to do that?

Re: facemenu-unlisted-faces

[Chong Yidong]

>     Assuming the facemenu is meant for users to select a face to put into
>     whatever buffer they are editing (via Edit->Text Properties->Face), I
>     would argue that the facemenu should be populated by an include list
>     rather than an exclude list.  I suggest just the following:
>
> Yes, I agree that would be better.  Nowadays, Emacs has a lot more
> faces than in the past, and nearly all of them need to be excluded.
>
> Would you like to do that?

Done.  I deleted facemenu-unlisted-faces and made a new variable
facemenu-listed-faces.  I've also updated etc/NEWS accordingly.