From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rainer M Krug Newsgroups: gmane.emacs.help Subject: Re: custom-themes BAD? Date: Tue, 25 Feb 2014 20:33:43 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1393356847 12050 80.91.229.3 (25 Feb 2014 19:34:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 19:34:07 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Dan Espen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 25 20:34:15 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 1WINle-0006ex-60 for geh-help-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 20:34:14 +0100 Original-Received: from localhost ([::1]:36757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WINld-0008Vf-IF for geh-help-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 14:34:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WINlJ-0008Tm-LF for help-gnu-emacs@gnu.org; Tue, 25 Feb 2014 14:33:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WINlE-000084-7L for help-gnu-emacs@gnu.org; Tue, 25 Feb 2014 14:33:53 -0500 Original-Received: from mail-wg0-f48.google.com ([74.125.82.48]:65413) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WINlD-00007y-Ur for help-gnu-emacs@gnu.org; Tue, 25 Feb 2014 14:33:48 -0500 Original-Received: by mail-wg0-f48.google.com with SMTP id b13so828728wgh.19 for ; Tue, 25 Feb 2014 11:33:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=p/JnsFBeqMSre8P/0qWiuQjcGdozfOX0KX8aMt3y1bo=; b=SYtB4buUkbGZyhnk+hFhm6MKEhU0mvsrpIysnVD3jLtRVyZ1ZD2onVeq0totJL67rc dH6KOUGf5J7m8xUf1Wjnwq/Euw9Mzzxd/3GK302BN3dfVKyzGRRYEoAP9MgGhrUeecYX swcb1/5HU8I4GRaMXk3L7naho5gmn+WrOLd19VLKHpdJoA3tefDvOLDMtbCqb1szXcPE 283VTeKoZxjiNBtAzvbFT3vsXwiZje2JPvQzgIvnt0gJTzcQT4diWvVj4gPk4fm6DcvO 0No49O1fTbdvcCzE2ujYUm/ascZg4+tAaUHyBi7jDOxfNnQd9z/J5c3pCRGtGA937N3Q LWGg== X-Received: by 10.194.192.104 with SMTP id hf8mr3748084wjc.65.1393356827179; Tue, 25 Feb 2014 11:33:47 -0800 (PST) Original-Received: from Rainers-MacBook-Pro-2.local (arn78-1-88-186-171-7.fbx.proxad.net. [88.186.171.7]) by mx.google.com with ESMTPSA id f7sm53217246wjb.7.2014.02.25.11.33.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2014 11:33:46 -0800 (PST) In-Reply-To: (Dan Espen's message of "Tue, 25 Feb 2014 13:03:49 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.48 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:96200 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dan Espen writes: > Drew Adams writes: > >>> When we get to packages like gnus, gnus goes ahead and >>> defines it's own faces: >>>=20 >>> 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 >>>=20 >>> That's the problem, there should be font-lock faces like: >>>=20 >>> 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. >>>=20 >>> 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. Now this is an important point and raises one question: there is a load-theme function - but not an unload-theme which removes the customizations done by the package? An author of a theme can not be expected to undo all changes another theme might have done - but one could expect a package author to provide a function which unloads the theme and restores the theme used before, or simply reset to the default values. IMO, this is the problem with themes. Cheers, Rainer > > 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. Tue, 25 Feb 2014 13:03:49 -0500 (1 hour, 25 minutes, 11 seconds ago) Organization: A noiseless patient Spider Drew Adams writes: >> When we get to packages like gnus, gnus goes ahead and >> defines it's own faces: >>=20 >> 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 >>=20 >> That's the problem, there should be font-lock faces like: >>=20 >> 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. >>=20 >> 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 =2D-=20 Rainer M. Krug email: RMKruggmailcom --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJTDPAXAAoJENvXNx4PUvmC27AIALx/nn2Frn2fe3vMdy61rTvn dz3GO6ZpxDQGZ9ozk7JIAuSS/8ae8RWtljFJXTBWirlOBqaYjtZKZtVIoEYRgeBS 3joCQzi89Z2awj3nyA/X2OkeH0odbYLVmx1yg0adsJ81SnFfoWjhCXbRlWM8gdb8 yktlB/eG4A4x9otiLXz3qcJl1xdHbdpfcLJN5guFedRa9qnljGCGza1CpL1CPL1n C1Uwvo0FsxKUhAqaQ/B5YU2nlx8rBy5qiSR+ZH+JFgeDgg/54MjFCZ9dkwlkcysz cdkjlKYP0hQyfuJi2/hmDa11RJnc579HE+NPw0Mniaa6avfL4Lx+PpbAu9kDE1o= =SKgZ -----END PGP SIGNATURE----- --=-=-=--