Re: reducing defface redundancy

[Miles Bader]

Per Abrahamsen <address@hidden> writes:
> Please, always remember that the usability of the defface UI is far
> more important than the usability of the defface Lisp interface.
> defface is really a sibling to defcustom.

They have different constraints though:

Since the defface spec is used by default, by _all_ users of emacs, it
has to be very flexible, and deal with all sorts of possible environments.
The changes I described would be very useful for allowing it to do that
job better.

The face-customization UI on the other hand, is only used by a single
user to define his personal faces; since a given user generally uses
only a small number of different environments, he usually doesn't need
all that flexibility, and is happy with a simpler representation.

> So when making changes to the defface, please consisder first:
> 
> 1. How will these changes affect the UI?

It need not affect it at all.

Remember, by default (unless you select `Show All Display Specs'), the
face customization widget basically tosses out all the clauses of the
current defface spec except the active one.  So, 99% of the time, the
user only deals with the _current_ definition of a face, and is happy.

So, the question is, what should be done for the advanced user, that
really does want to define a complex face using the UI, that works
under different display types?

If my proposal for defface is adopted, I forsee the UI interface
basically `flattening' the defface spec before passing it to the widget.
In other words, it would percolate up all conditional and `or' clauses
to the top-level so the result looks like a traditional defface spec
(in the case of an `or' vector this would result in the vector being
translated into conditional clauses, using the `capable' test I
suggested).

Indeed, this flattening could happen when the defface macro is
expanded, if the flattened form is easier for the infrastructure to
deal with (certainly it would make implementation easier, since
wouldn't have to change any existing functions except defface!).

Here are some examples of flattening:

  1) My previous example `subtle-yet-underlined-mode-line':

      (:inherit mode-line
       :underline t
       ((((background light)) :background "grey90")
        (((background dark))  :background "grey10"))))

     Flattens into:

      ((((background light))
        :inherit mode-line
        :underline t
        :background "grey90")
       (((background dark))  
        :inherit mode-line
        :underline t
        :background "grey10"))

  2) My previous example `emph-yellow':

      (:foreground "yellow"
        [(:weight bold) (:slant italic) (:underline t)]))

     Flattens into:

      ((((capable :weight bold))
        :foreground "yellow"
        :weight bold)
       (((capable :slant italic))
        :foreground "yellow"
        :slant italic)
       (t
        :foreground "yellow"
        :underline t))

So as you can see, my proposal really is just a way to make defface
easier and more convenient.  It won't make the UI any less useful, or
indeed even change it.

And remember, it doesn't just make defface specs less redundant, it also
makes it possible to write _simpler_ defface specs, which more closely
follow the thinking of the face designer.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
                        -- Walter Hines Page