[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.
-Miles
--
The secret to creativity is knowing how to hide your sources.
--Albert Einstein
- Re: reducing defface redundancy, Miles Bader, 2002/07/03
- Re: reducing defface redundancy, Kai Großjohann, 2002/07/03
- Re: reducing defface redundancy, Kim F. Storm, 2002/07/03
- Re: reducing defface redundancy, Richard Stallman, 2002/07/08
- Re: reducing defface redundancy,
Miles Bader <=
- Re: reducing defface redundancy, Richard Stallman, 2002/07/09
- Re: reducing defface redundancy, Richard Stallman, 2002/07/09
- Re: reducing defface redundancy, Stefan Monnier, 2002/07/09
- Re: reducing defface redundancy, Richard Stallman, 2002/07/10
- Re: reducing defface redundancy, Stefan Monnier, 2002/07/11
- Re: reducing defface redundancy, Miles Bader, 2002/07/11
- Re: reducing defface redundancy, Richard Stallman, 2002/07/12