Re: reducing defface redundancy

[Miles Bader <miles@lsi.nec.co.jp>]

Richard Stallman <rms@gnu.org> writes:
> Simple face customization is clean now because it affects just one
> alternative, and it is easy and well-defined to select just the
> alternative that applies.
> 
> With your propose defface change, the attributes actually specified
> would not come from a single alternative in a simple way.  So the
> customization of the active parts of the defface spec would raise
> difficult issues.  If the user adds a new attribute, where in the
> structure does it go?

I replied to Per's question about this in some detail, but here's the
short version: You can think of the grammar I outlined as merely being a
convenient shorthand for the defface user; it's not hard to convert it
into exactly the same `simple but redundant' 2-level format that the UI
uses now.

In fact, this transformation can be done in defface (or rather, in the
code the defface macro expands into), before any other part of emacs
sees it; this would keep implementation simple.

Of course, in order to support the display `capability querying'
feature, a new type of test has to be added to the set that the UI and
other parts of the face code recognize, but that's an orthogonal issue
to the change in the defface grammar (and it's not hard to do either).

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.