[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reducing defface redundancy

From: Miles Bader
Subject: Re: reducing defface redundancy
Date: 09 Jul 2002 10:25:37 +0900

Richard Stallman <address@hidden> writes:
>     So basically the rewritten face spec will look like the original
>     face-spec except with the user's changes integrated.
> I think users will find this surprising and inconsistent.

Can you say why you think this?  I think it gets about as close as we
can to `doing the intuitive thing' when a someone uses the simple face
customization -- it's really impossible to always do things correctly,
since we'd have to read the user's mind.

Remember that the way I suggest integrating the user's changes follows
the structure set up by the face creator, and possible user
customizations are one thing to think about when creating the face.

> In addition, we want to have buffer-local face definitions, and that
> will make this issue even more complex.

It depends on how buffer-local face definitions are implemented.  My
feeling is that there _shouldn't_ be real buffer-specific faces, but
rather a way of remapping faces within a buffer.  For instance foo-mode
could make the `foo-default' be used as the default face within its
buffers; if the user want's to change it, they'd have customize
`foo-default', not `default' (though the customization widget could
notice that there's a buffer-local remapping, and ask the user `do you
want to edit the global `default' face, or the `foo-default' face being
used in this buffer').

> You can customize a face for the current display, for the current
> session, looking at a simple list of attributes, but you cannot save
> this.  Or you can customize the conditional commands that define the
> face, by looking at the whole structure of them.  That kind of
> customization you can save if you wish.

Well that would certainly get rid of the ambiguity, but I suspect that
most users would absolutely hate it (I certainly would) -- it attempts
to solve a fairly rare problem (face customizations that have surprising
results on other display types) by making the _normal case_ more
inconvenient and confusing!

I think this is a case where it's possible to do a good job
automatically most of the time.  Since the problems that might arise are
fairly minor (the face looks a bit funny), I think they're well
justified by the extra convenience and utility for users in the common
case from doing things automatically.

The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

reply via email to

[Prev in Thread] Current Thread [Next in Thread]