Re: Eliminating a couple of independent face definitions

[Tim Cross]

On Thu, Feb 3, 2011 at 4:17 AM, Chong Yidong <address@hidden> wrote:

Tim Cross <address@hidden> 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