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: Thu, 3 Feb 2011 08:24:09 +1100 Message-ID: References: <87oc6vm67v.fsf@stupidchicken.com> <87vd12z77n.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001485ebea380c4169049b53453c X-Trace: dough.gmane.org 1296681936 15633 80.91.229.12 (2 Feb 2011 21:25:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 21:25:36 +0000 (UTC) Cc: Lennart Borgman , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 02 22:25:31 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 1PkkCR-0003Oo-SM for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2011 22:25:31 +0100 Original-Received: from localhost ([127.0.0.1]:53655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkkCA-00062G-Kv for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2011 16:24:58 -0500 Original-Received: from [140.186.70.92] (port=42261 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkkBv-0005wu-H9 for emacs-devel@gnu.org; Wed, 02 Feb 2011 16:24:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkkBO-0003xi-U1 for emacs-devel@gnu.org; Wed, 02 Feb 2011 16:24:16 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:65077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkkBO-0003xc-NV for emacs-devel@gnu.org; Wed, 02 Feb 2011 16:24:10 -0500 Original-Received: by iyi20 with SMTP id 20so450624iyi.0 for ; Wed, 02 Feb 2011 13:24:10 -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=47td/ODTqQa8kmeKTN0/P0avqGLWewc6nt5a3gd8lhY=; b=i2B9gdwkO1dGbgcKq+fgWhltel7vJdGWUAmMF7gS/o2lgQa+0CXcNAvM7EoQmHTVxV SMiDcsGER2HG10eIPd8UfSxHMwAsCHZb65LmwMJTX+BPVD+wDcG15YgI3bnrZuSbcKWV i146rCzFW97pYyRXGDMZ/yzuzE/fpFvmlBmzo= 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=fie4DtsuY/X8hMN9/Yp0sM7AoG1Kf2szOsAUMvUoIvS8kL9Jkfoy9xBzA0YtwEg/Lw rP2wg9SjIkHb9S5Nz/s2FZYDNYr+fPbOeeK2m76wiLj6ZYzPusm3TwZSMwheiK8sZaSR 2Z/a8igyMPYjRmWaajLeonJGIkYMFgav0oyIo= Original-Received: by 10.231.59.149 with SMTP id l21mr10581034ibh.196.1296681849862; Wed, 02 Feb 2011 13:24:09 -0800 (PST) Original-Received: by 10.231.19.67 with HTTP; Wed, 2 Feb 2011 13:24:09 -0800 (PST) In-Reply-To: <87vd12z77n.fsf@stupidchicken.com> 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:135487 Archived-At: --001485ebea380c4169049b53453c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 3, 2011 at 4:17 AM, Chong Yidong wrote: > Tim Cross 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 --001485ebea380c4169049b53453c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 3, 2011 at 4:17 AM, Chong Yi= dong <cyd@stu= pidchicken.com> wrote:
Tim Cross <th= eophilusx@gmail.com> writes:

> My only concern is how you define what to inherit from. For example, > in your suggestion of compiler warnings inheriting form
> =A0font-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 fa= ce than font-lock-comment as comments are often coloured so as to be a litt= le less noticeable, while warnings are probably something you want to notic= e (but not as much as errors!).=A0

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.=A0

As someone who has a vision impaired and has somewhat s= pecial requirements for font properties and someone who has maintained pack= ages that use a number of faces, I know how hard it can be to select approp= riate defaults. I frequently find packages which have poor defaults or defa= ults which only work for systems with a light/white background. Although fa= ces have the facility to be defined with multiple options depending on the = display type or background, it seems not many packages take advantage of th= is. My main reason for supporting the notion of using inherit is that it co= uld 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 u= ser with the ability to modify if necessary. I prefer inherit over just usi= ng a variable holding a face name as the user can modify things without hav= ing to know what other faces to choose from (and knowing the face they choo= se is always defined and not just defined at the time they use something li= ke list-display-faces to find an alternative).=A0

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 al= l the gnus faces without 'doubling up' and losing some distinction = between different faces. However, I don't think the suggestion was to m= ake *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 =A0making more use of inherit is a good i= dea. Stephan may be right in that we could need a larger set of 'core&#= 39; font-lock-* faces to make this work and I still think we would need som= e guidelines/principals to help developers know which would be the most app= ropriate 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 environment= s and give users a better initial default experience while allowing maximum= flexibility in individual configuraiton with minimal knowledge.=A0

Tim
--001485ebea380c4169049b53453c--