emacs-devel
[Top][All Lists]
Advanced

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

Re: Eliminating a couple of independent face definitions


From: Tim Cross
Subject: Re: Eliminating a couple of independent face definitions
Date: Wed, 2 Feb 2011 16:02:00 +1100



On Wed, Feb 2, 2011 at 3:11 PM, Lennart Borgman <address@hidden> wrote:
On Wed, Feb 2, 2011 at 5:05 AM, Chong Yidong <address@hidden> 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

reply via email to

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