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.