Re: Eliminating a couple of independent face definitions

[Tim Cross <theophilusx@gmail.com>]

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

On Wed, Feb 2, 2011 at 3:11 PM, Lennart Borgman
<lennart.borgman@gmail.com>wrote:

> On Wed, Feb 2, 2011 at 5:05 AM, Chong Yidong <cyd@stupidchicken.com>
> wrote:
> > It would be nice if almost all faces in packaged included with Emacs
> > inherit from the basic or font-lock faces.  Most faces already do this.
> > This way, users don't have to specify as much when they write a Custom
> > theme or their own personal face customizations.
> >
> > I'd like to inherit-ize most of the remaining faces that don't already
> > do this.  For instance, compilation-warning is currently "Orange", and
> > compilation-info is "Green3"; I want to make them inherit from
> > font-lock-doc-face and font-lock comment-face respectively.  (The rest
> > of the compilation-mode already inherit from font-lock faces.)
> >
> > There are a few more similar changes here and there.  Any objection?
>
> Yes.
>
> It is really good to try to merge some faces, but the specific merges
> you mentioned seems a bit unfortunate. The colors were obviously
> chosen to fit into those used in society for "ok" and "warning". Why
> not create new faces for such things? (I do not think the font-lock
> faces have the same meaning tighed to them, but maybe I am wrong
> there.)
>
> I think the concept of using inherited faces so that all packages inherit
from a few well designed faces i.e. have appropriate definitions for
light/dark backgrounds, work on the console, in a terminal, under X, on
windows etc, is a good one. Having a few base faces to maintain in this way
would seem like a positive move and I agree it would make defining custom
themes easier. In fact, Ive recently been doing exactly this for VM
primarily because I thought it was better to use 'core' faces in that
package as they were more likely to be defined based on sound reasoning,
testing and feedback and would more likely be acceptable to a larger number
of users.

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?
It isn't clear to me what rationale would guide the decision as to what base
face to  inherit from. Without this, the choices could become rather
arbitrary and could make face customization or theme definition
even more difficult, resulting in apparently arbitrary use of font lock
properties (which may be OK, I don't know).

It would probably be sufficient to have a clear guideline or set of
recommendations which could be applied by developers when deciding on what
face to inherit from. However, this probably needs to be done prior to
changing definitions to use inherit. I would not expect to get it right or
even get consensus on the first go, but it could be refined and improved.
Developers may also be more likely to use :inherit if they feel there is
some guidance on what to inherit from.

Tim

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