Re: reducing defface redundancy

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

Richard Stallman <rms@gnu.org> writes:
>     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.
> 
> I am not convinced that is a good solution to the issue of what
> Custom should do.  Suppose I give a face one unconditional attribute,
> and suppose the user customizes that attribute with Custom.
> Should his customization always be recorded only for the one kind
> of screen he is actually using?

Well, there are two interfaces used by the (current) custom face UI:

  * The current-display-type-only interface, which is the default.  This
    displays the face used by the current display, and if the user
    changes something in the face and saves it, the current face
    attributes become unconditional for all display types (trashing any
    display-type-conditionalization that was defined by the defface
    specification for that face).

  * The many-display-types interface, which the user has to explicitly
    enable.  This displays all the various conditional faces that
    defface defined, and allows the user to change any of them.  This
    doesn't trash any information.

My suggestion of flattening the grammar, and using the current UI,
wouldn't change any of this.

If the user choose the 2nd (many-display-types) UI, and there's a
`common' attribute in the defface spec, he will see that common
attribute replicated in each face displayed by the face UI.  Having to
tweak it for each displayed face might be a little annoying, but it
seems to make sense from a UI point of view (a more complex UI that
actually mirrored the defface grammar could solve this, perhaps, but the
additional complexity could make the situation much more confusing).

However, for the 1st UI (current-display-type-only), it might be a
useful try and detect changes to `common' attributes and preserve a
modified version of the original defface spec, instead of just trashing
it as the UI does now.

Anyway, my point is that the new grammar won't make anything worse, and
may provide some additional leeway for improvement.  However, I don't
think clever handling of common attributes in the UI is necessarily a
requirement for an initial implementation (given that there doesn't seem
to be any complaint about the current UI trashing things).

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.