Re: reducing defface redundancy

[Miles Bader]

Richard Stallman <address@hidden> writes:

>     The basic idea is to allow using a lisp vector ([...]) as a kind of `or'
>     expression in the attribute part of a defface clause.
> 
> Your proposal makes a number of other changes;
> is this the best way to do all of them?
> 
> I don't see how an "or" construct would be a kind of clause:
> 
>       CLAUSE    ::= ATTRIBUTE
>                 | (TESTS CLAUSE...)             ; traditional top-level style
>                 | [SPECS ...]                   ; `or' vector style
> 
> Shouldn't it be a kind of TEST instead?

Well, it's not really an `or' in the exact same sense as a typical or
function used in lisp, say.

It's more like the alternatives used for a prolog rule or something, it
tries each element in order until it finds out that is `supportable'.

So a user can just write:

    [ALTERNATIVE1 ALTERNATIVE2 ... DEFAULT]

and the lisp code will effectively say `does the display support all
the attributes ALTERNATIVE1?  If so, lets use that.  If not, does the
display support all the attributes in ALTERNATIVE2?  ...' etc.

I think this often _exactly_ what people are actually _thinking_ when
they design a defface spec (they want a certain effect for the face, and
can think of several physical appearances that might convey it).

[Note that the I've suggested adding the `capability testing' as a
traditional TEST as well, in case someone wants to use that instead.]

I do think, BTW, that the ability to write non-conditional defface
specs with this grammar is a benefit, since I always get annoyed that
I've got to stick in the ((t ...)) crap even when I know I don't need
any tests...  :-)

-Miles
-- 
Would you like fries with that?