From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Eliminating a couple of independent face definitions Date: Wed, 2 Feb 2011 16:02:00 +1100 Message-ID: References: <87oc6vm67v.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001485ebea38993281049b458c0d X-Trace: dough.gmane.org 1296622948 1339 80.91.229.12 (2 Feb 2011 05:02:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 05:02:28 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 02 06:02:24 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PkUrB-0007HY-Fn for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2011 06:02:24 +0100 Original-Received: from localhost ([127.0.0.1]:45948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUr6-0003Ht-1f for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2011 00:02:12 -0500 Original-Received: from [140.186.70.92] (port=54881 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUqx-0003GD-UU for emacs-devel@gnu.org; Wed, 02 Feb 2011 00:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkUqw-0006Uf-2L for emacs-devel@gnu.org; Wed, 02 Feb 2011 00:02:03 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:63550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkUqv-0006US-Tz for emacs-devel@gnu.org; Wed, 02 Feb 2011 00:02:02 -0500 Original-Received: by iyj17 with SMTP id 17so7980622iyj.0 for ; Tue, 01 Feb 2011 21:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=17lV0eMevBDMhDtL7cDaAckxA7EsDVk6QU0n3UhtRT8=; b=i554LfuyiTO0zztKp6XzyBiAnQ8uJ13vOqJBchu1U674+LeSRv7ynSp/m78WLKfvvT vzEKQRkE4G4mphnjVPqR4eH26oXUyx2OHqmYW7OR8O459jWTnnzsfUwS7gdFk4ROZsR5 fe2GqBwI3cypIvxP86XDAHXV+HXmQuadk2xw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yeaiyrpv4Y3yS6sVN8vBOcollc4uoz9qTdmpbIY97GyFkBa785RPErFthQA9n07/7Y vn54R7Xn4ki1KNs9jeuYYPEEYCeAyrW5deVu2LVLIp9r7or8YW/jtlKDjcVFqOJLZIns fhxyxwnvOYeQ59XNCvzQdFjvulzQCVPMEFqkg= Original-Received: by 10.231.59.149 with SMTP id l21mr9418591ibh.196.1296622920741; Tue, 01 Feb 2011 21:02:00 -0800 (PST) Original-Received: by 10.231.19.67 with HTTP; Tue, 1 Feb 2011 21:02:00 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:135453 Archived-At: --001485ebea38993281049b458c0d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 2, 2011 at 3:11 PM, Lennart Borgman wrote: > On Wed, Feb 2, 2011 at 5:05 AM, Chong Yidong > 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 --001485ebea38993281049b458c0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 Yid= ong <cyd@stupidchicken.com&= gt; wrote:
> It would be nice if almost all faces in packaged included with Emacs > inherit from the basic or font-lock faces. =A0Most faces already do th= is.
> This way, users don't have to specify as much when they write a Cu= stom
> theme or their own personal face customizations.
>
> I'd like to inherit-ize most of the remaining faces that don't= already
> do this. =A0For instance, compilation-warning is currently "Orang= e", and
> compilation-info is "Green3"; I want to make them inherit fr= om
> font-lock-doc-face and font-lock comment-face respectively. =A0(The re= st
> of the compilation-mode already inherit from font-lock faces.)
>
> There are a few more similar changes here and there. =A0Any 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 "warni= ng". 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 defi= nitions for light/dark backgrounds, work on the console, in a terminal, und= er 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 definin= g custom themes easier. In fact, Ive recently been doing exactly this for V= M 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 reasonin= g, testing and feedback and would more likely be acceptable to a larger num= ber of users.=A0

My only concern is how you define what to inherit from. For = example, in your suggestion of compiler warnings inheriting form =A0font-lo= ck-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 =A0inherit from. Without this, the choices= could become rather arbitrary and could make face customization or theme d= efinition=A0
even more difficult, resulting in apparently arbitrary use of font loc= k properties (which may be OK, I don't know).=A0

It would probably be sufficient to have a clear guideline or set of reco= mmendations 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. Developer= s may also be more likely to use :inherit if they feel there is some guidan= ce on what to inherit from.

Tim
--001485ebea38993281049b458c0d--