From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: face inheritance [was: Find out what is setting color in minibufer] Date: Sun, 27 Nov 2016 10:15:25 -0800 (PST) Message-ID: <9bf187d0-a2a9-4e2d-93bb-8368030f92c0@default> References: <87wpfqt679.fsf@gmail.com> <87shqet338.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480270565 1320 195.159.176.226 (27 Nov 2016 18:16:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 Nov 2016 18:16:05 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Alex Kost , Fernando Basso Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 27 19:16:01 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cB3zc-0008Do-NO for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Nov 2016 19:16:00 +0100 Original-Received: from localhost ([::1]:55124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cB3zg-00030W-IG for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Nov 2016 13:16:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cB3zG-00030R-Dk for help-gnu-emacs@gnu.org; Sun, 27 Nov 2016 13:15:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cB3zD-0003Qw-6C for help-gnu-emacs@gnu.org; Sun, 27 Nov 2016 13:15:38 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:31276) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cB3zC-0003Qe-Rn for help-gnu-emacs@gnu.org; Sun, 27 Nov 2016 13:15:35 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uARIFS7i004787 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Nov 2016 18:15:29 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uARIFSuG015707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Nov 2016 18:15:28 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uARIFQug022855; Sun, 27 Nov 2016 18:15:27 GMT In-Reply-To: <87shqet338.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.help:111814 Archived-At: > After all, I would say it's a Geiser problem: faces should=20 > inherit from other (particuarly 'font-lock') faces and > should not copy their specs as it is done in Geiser faces. I have nothing to say about the particular question raised in this thread. But I have a comment about the last, "faces=20 should" statement (which is a _general guideline_ and, like my comment, not a judgment about this particular Geiser situation): I could not disgree more - both with the general claim and with the "particularly 'font-lock'" part. Code should NOT create faces that inherit from other faces, unless the intention is precisely to create such a default dependence (only by default, since faces can always be customized). In particular, faces should generally NOT inherit from font-lock faces, unless you really want/need such a dependence. If you don't believe me, just ask yourself what happens when a user customizes your new face: the dependence is gone. If you are relying on it as more than just a convenience for defaulting attribute values, then you are out of luck. And if for some reason your code really needs such a dependency to remain, so that there is no way to customize the new face, and the only change a user should make is to=20 customize the inherited (e.g. font-lock) face, then your code should just use that face directly and not define a new face that inherits from it. The easiest way to see what the right approach is for your code is to play user and customize the face. If the result is broken behavior then you should not have defined the face in the first place. If you define a face, then users are, and should be, able to change it. If your code tries to highlight something with that face, and if that something is also being highlighted by some other code, in particular by font-locking, then that is a conflict that you need to take care of. It should be quite possible for a user to customize certain faces whose effect is NOT changed by imposing or changing a theme. Other faces, on the other hand, are expected to be changed by a given theme. A theme typically does not affect all faces. It all depends on what you want for your code, including what you want its users to be able to do. IMHO, there is far too much code that defines faces using inheritance (and this includes some in the distributed Emacs code). That can be useful, but its strength is also its weakness: Any change to the inherited face affects the new face - unless the user customizes the latter. Faces are defined for a given initial context. When they are reused for a completely different context the result is something else again. If the contexts are similar enough then the reuse might still work; otherwise, it might not. For example, a particular color for a font-lock face such as `font-lock-lock-keyword-face', might make perfect sense for typical font-lock, programming contexts. But it might not make sense for some other context - even if it might seem to its author to look good in the default context. Font-lock faces, in particular, work together. If a user changes one or two to fit her context, she may also change some of the others. The reflection of such a change in the context of a library that defines a face that inherits from a font-lock face will not necessarily be TRT. And that can force a user to customize the face that inherits. When you use a face for your library, ask yourself how similar its use/behavior is to that of a face defined for another context: * If it is very, VERY similar, then you might want to just use that existing face (no new face). * If it is very similar, but you want users to be able to change it independently, then you might want to use a new face that inherits from the existing face. * If it is not very similar then you might want to define it without using inheritance. In particular, do NOT inherit from a face just because you think its default attributes (e.g. colors) are appropriate as defaults for your context. If that is the ONLY reason you are considering inheritance then just define a new face with the same attribute values - no inheritance. The goal should be to do something appropriate for your specific context that is also the most helpful for users. The goal should NOT be to minimize the number of faces.