Re: Eliminating a couple of independent face definitions

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]

On Thu, Feb 3, 2011 at 4:17 AM, Chong Yidong <cyd@stupidchicken.com> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > My only concern is how you define what to inherit from. For example,
> > in your suggestion of compiler warnings inheriting form
> >  font-lock-comment-face I immediately wondered why you would not
> > inherit from font-lock-warning face?
>
> font-lock-warning-face is already used for compilation errors, which are
> more serious than warnings.
>

OK, that makes it clearer. Maybe a different face than font-lock-comment as
comments are often coloured so as to be a little less noticeable, while
warnings are probably something you want to notice (but not as much as
errors!).

WRT Drew's comments. Some good points. However, to make my position clear, I
would not suggest that packages don't define their own faces, only that they
use inherit to define the default value the face has. Individual users then
have the option to change that individual face if desired.

As someone who has a vision impaired and has somewhat special requirements
for font properties and someone who has maintained packages that use a
number of faces, I know how hard it can be to select appropriate defaults. I
frequently find packages which have poor defaults or defaults which only
work for systems with a light/white background. Although faces have the
facility to be defined with multiple options depending on the display type
or background, it seems not many packages take advantage of this. My main
reason for supporting the notion of using inherit is that it could mean we
may have a set of well defined core faces that developers could use to
provide good defaults, but at the same time, leave the individual user with
the ability to modify if necessary. I prefer inherit over just using a
variable holding a face name as the user can modify things without having to
know what other faces to choose from (and knowing the face they choose is
always defined and not just defined at the time they use something like
list-display-faces to find an alternative).

Stephan has also raised important points. The existing set of 'standard'
faces is not extensive enough to meet all needs. Gnus is probably a good
example. You could not currently use inherit for all the gnus faces without
'doubling up' and losing some distinction between different faces. However,
I don't think the suggestion was to make *all* package faces use inherit -
but of course, if its not all, which ones will it be and how is that
determined?

I still think  making more use of inherit is a good idea. Stephan may be
right in that we could need a larger set of 'core' font-lock-* faces to make
this work and I still think we would need some guidelines/principals to help
developers know which would be the most appropriate face to inherit from.
Doing this would make it easier to maintain a set of well defined core faces
that would work well under all environments and give users a better initial
default experience while allowing maximum flexibility in individual
configuraiton with minimal knowledge.

Tim

[-- Attachment #2: Type: text/html, Size: 3620 bytes --]