From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Espen Newsgroups: gmane.emacs.help Subject: Re: custom-themes BAD? Date: Tue, 25 Feb 2014 13:03:49 -0500 Organization: A noiseless patient Spider Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393351517 7663 80.91.229.3 (25 Feb 2014 18:05:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 18:05:17 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 25 19:05:21 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WIMNd-0004I8-68 for geh-help-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 19:05:21 +0100 Original-Received: from localhost ([::1]:36404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIMNc-0002fs-ID for geh-help-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 13:05:20 -0500 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-2.dfn.de!news.dfn.de!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 106 Injection-Info: mx05.eternal-september.org; posting-host="189748f827f5005aa08ac3cba2786117"; logging-data="19403"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18eFHpy2M1D8Tb0gVtaycfg4UsDpf9VRmE=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:TCfgERTyDiT0Hcp3gria4Vd8aXE= sha1:fTAUpl01BvlrWGXQ9kKcjin4k8c= Original-Xref: usenet.stanford.edu gnu.emacs.help:203929 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:96198 Archived-At: Drew Adams writes: >> When we get to packages like gnus, gnus goes ahead and >> defines it's own faces: >> >> gnus-cite-attribution-face >> gnus-cite-face-1 >> gnus-cite-face-2 >> gnus-cite-face-3 >> gnus-cite-face-4 >> gnus-cite-face-5 >> gnus-cite-face-6 >> gnus-cite-face-7 >> gnus-cite-face-8 >> gnus-cite-face-9 >> gnus-cite-face-10 >> gnus-cite-face-11 >> gnus-emphasis-bold >> gnus-emphasis-bold-italic >> >> That's the problem, there should be font-lock faces like: >> >> font-lock-bold, >> font-lock-level-1 thru 12, >> font-lock-large-1,,, >> font-lock-blue... >> font-lock-reverse > > Those are not existing font-lock faces, AFAIK. They are certainly > not defined by library `font-lock.el'. I know that, that was my point, they (or something like them) should be available. >> and so on. >> >> All the packages should be using font-lock-* faces as far as >> possible. Then the themes can all set the same set of faces >> much more easily. > > I cannot speak to whether it is appropriate for Gnus to define > faces for its use here or whether it should instead just use > common font-lock faces instead. I do not use Gnus. I'm only using GNUS as an example. Take a look at manoj-dark-theme. You'll see the problem. > That kind of question needs to be decided on a case-by-case > basis. I only want to add here that it is NOT the case that > libraries "should" reuse font-lock faces, in general. They > should use font-lock faces when that makes sense, and not > otherwise. > > The advantage of reusing a common face is the same as the > disadavantage: change it once here and it gets changed everywhere > it is used. That makes some things easier and others more > difficult. > > What is especially pernicious, IMO, is *hard-coding* the use > of a particular face, rather than providing a new face whose > default appearance *inherits* from that face. > > That makes it unnecessarily difficult for a user to customize > the use of that particular highlighting. > > E.g., a given library `foo.el' might well define a face > `foo-emphasis', which might inherit its default appearance from > the basic face `italic'. It is then easy for a user to > customize the appearance of that Foo highlighting without > affecting use of face `italic' throughout Emacs. > > If, instead, `foo.el' just uses face `italic', then the user > loses flexibility: s?he must change the appearance everywhere > or nowhere. > > If a library defines a new face, but inherits its default > appearance from another face, a user can customize either the > parent face or the child. In the former case, the result is > the same as in the hard-coded context: customize once to > change the appearance everywhere (everywhere that inherits). > So you really lose nothing by defining a library-specific face. > > Other people, including some Emacs maintainers, disagree. > The result is that we still have some hard-coded uses of general > faces, rather than letting users decide easily. > > With no knowledge of Gnus and its faces, I'll ask: just what > is the problem that you are trying to raise here, wrt custom > themes? Is it that lots of faces means theme size is too large? > IOW, it's not clear to me what your point is. If you use manoj-dark theme, then switch to another theme, manoj will leave behind a huge number of it's customizations, since other themes don't set as many fonts. manoj-dark is 800 lines. Too many for the other theme creators to deal with. A theme should be able to change all the colors a user is likely to see. A set of generic fonts that packages can inherit from should solve the problem. The font-lock faces are fine, they just don't go far enough. -- Dan Espen