So to make a face in Emacs 21 now, you do: (make-face 'foo) (set-face-attribute 'foo nil :family "lucidatypewriter" :width 'normal :height 200 :weight 'normal :foreground "red" :background "pink" :strike-through t)

William M. Perry writes: > So to make a face in Emacs 21 now, you do: > > (make-face 'foo) > (set-face-attribute 'foo nil > :family "lucidatypewriter" > :width 'normal > :height 200 > :weight 'normal > :foreground "red" > :background "pink" > :strike-through t) Well, I almost like this setup. The thing I don't like is a face having all these properties. A property list like this should be recognized as an instantiator for a font specifier.

Ben Wing writes: > Why not add built-in face properties like font-family, > font-weight, font-slant, etc.? Otherwise you arbitrarily > stick some properties inside of property lists hung off a > single property, and other properties are direct face > properties. Ugly ugly ugly. Keep it simple. I think the font specifier route is the simple route. Font proerties are not face properties any more than glyph properties are extent properties. Making [font :family "lucidatypewriter" :width 'normal :height 200] an instantiator means that old code keeps working. We don't have to worry about what happens when some code does (set-face-font 'foo "fixed") and some other code sets all these new face properties. Which code should win? Why? We don't have to worry about the surprising new ways fonts will be instantiated when all the new face font attributes are separately subject to the face inheritance rules, where currently only the entire font is subject to those rules. Do you really want to query fifteen different face properties to figure out what font is going to be used on a device? What is (specifier-instance (face-font 'foo)) going to do? Also in the example: > > > (set-face-attribute 'foo nil > > > :family "lucidatypewriter" > > > :width 'normal > > > :height 200 > > > :weight 'normal > > > :foreground "red" > > > :background "pink" > > > :strike-through t) foreground and background would not be part of the font instantiator since they are face properties.

Ben Wing writes: > Kyle, take a look at what other systems do, e.g. style sheets. > They don't make arbitrary distinctions like you're proposing. > All text-display properties are on the same level. There is > no "font" property. Yes, but style sheets are used under a different system with a different philosophy. Web documents are by necessity loosely specified with the client filling in the details. We are implementing a low level interface and need to specify exactly what we want, and also need to be able to easily access what someone has specified. For what we're doing, segregating device specific things like font information in a specifier looks exactly right to me. I see font specifiers being much like color specifiers. It is so much better to be able to (set-face-background 'foo "rgb:30/30/30" 'x) instead of having separate face properties for RGB values, HVC values and all the other color specification methods in existence. With a font specifier a programmer can specify things for X Windows and not worry about how Windows or some new OS we support is going to react to the generic font-family property. And when we need to find out what font is being used, the font specifier is quite handy. If we ignore XEmacs-Mule, it is easy to find out what font is being used in a window, and to find out if the font is window/buffer/frame/device-type specific. This looks a whole lot harder without a font specifier, and without constraints on the face properties that relate to the font specification. I appreciate that a style-sheet like interface is useful; giving the system a vague specificationa and letting it fill in the details is quite handy. But I don't think hacking together fonts and faces is the best way to achieve that flexibility. I think that it would be better to create a higher level construct for this purpose if we need one. > Compatibility arguments make little sense to me because we've > changed the way face attributes are handled many times in the > past, and not felt compelled to turn XEmacs into a "mode > monster" ala Intel chips. Yes, but it is time for this kind of wholesale rejiggering to stop. New ideas are good, but the world keeps running thanks to day-to-day compatibility. We are past the point where we can claim that the product is so new that we won't hurt many people by radically changing the APIs. We passed that point years ago.