From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Defaulting faces to inherit deemed harmful [was: Stealing a default face from a non-ELPA package] Date: Sun, 06 Mar 2022 05:38:55 +1100 Message-ID: <87r17gkxvg.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20294"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.9; emacs 28.0.91 Cc: emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 05 20:23:52 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQa0N-00056L-Sa for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Mar 2022 20:23:51 +0100 Original-Received: from localhost ([::1]:49794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nQa0M-0006MJ-DJ for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Mar 2022 14:23:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nQZzP-0005BR-3P for emacs-devel@gnu.org; Sat, 05 Mar 2022 14:22:51 -0500 Original-Received: from [2607:f8b0:4864:20::52b] (port=42720 helo=mail-pg1-x52b.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nQZzN-0005FK-Au for emacs-devel@gnu.org; Sat, 05 Mar 2022 14:22:50 -0500 Original-Received: by mail-pg1-x52b.google.com with SMTP id o8so10231940pgf.9 for ; Sat, 05 Mar 2022 11:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=Qr3ETYSXayp+zyRe2B9YqyOLZEeGSdbm+ms5TSRxs7M=; b=lAOl4ysPtasKUIGGz/v3MXJ+dqqlCzIfdtQ0+3lPnUljMWo12o0hnfQN7dtol55S2h 69CoreDo1A2junFqoZmPkYW9vwgE+fYMHjkzLbdMTM4rCkyaaLFA4fQnrL476wHLunsY VzlGkir4tJrTD9DdR/NTz3/lf72qjVXAY2aTL90hd8l1KD9oR4yKPC8ecN/gGMbmnIrf mNxsxmqVsWmSouNztloCPY/btsuZB1M+b4ulZPfNDEUGIu2JkbAwY1IDajeL6dW1JPHj fKFAk/PQCQFaV7cvhBnNhVFck1RL1Uja79E3tPm+i8APvyjuyxQapXGYHXLnq+ponxtg nAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=Qr3ETYSXayp+zyRe2B9YqyOLZEeGSdbm+ms5TSRxs7M=; b=0M0rSxWz1b0Khvrts6rLWwXVvmX22596uB42Q6KlsneOmxP2wQPiKJ3ub709eUPkD/ +ULgv0OwKnlTH6fjXoDlrazpg8E/wC+M8Ik56Hw/nHrJBrjKm7+RrHTc3Ps0kDKSJvgh Nm6YYTYVW5/5X71cxqHrOh069iB343T7Td84W56yLqtmGqdZZuboqK7B5UsPxmHpADRe mTB2ojS9GEdWpYn6Qvozs5BRcOTpirtncup5dyocbIVtIjGL97yhWzvplOjViT1zMCYt SefgfvFBI6OBX8DBm3xDxGAsdYAaN2LE2Iu0GqNRmI9fiin8HMFxXTkzfM6KK3ZL0MiH vIuw== X-Gm-Message-State: AOAM532dFx3KVvXvdO5FqrQe+D6Rijb0x2u81Rg3V+2fRfVRP+x+0cKU 5uh0WdAgLdn0ljrfIVQ9+svzwsV7TQA= X-Google-Smtp-Source: ABdhPJwAhQM2jSMuoNWHfwV7rbWrnvmTP7fhrEG8/qZLzgON0hiQ2llCD+ylwzPCT0GVUJWZjHT5kw== X-Received: by 2002:a63:2b48:0:b0:365:2766:7e5f with SMTP id r69-20020a632b48000000b0036527667e5fmr3712778pgr.613.1646508167479; Sat, 05 Mar 2022 11:22:47 -0800 (PST) Original-Received: from dingbat (106-69-94-169.dyn.iinet.net.au. [106.69.94.169]) by smtp.gmail.com with ESMTPSA id a20-20020a056a000c9400b004f396b965a9sm10052639pfv.49.2022.03.05.11.22.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Mar 2022 11:22:47 -0800 (PST) In-reply-to: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::52b (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52b.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:286842 Archived-At: Drew Adams writes: >> Personally, I wish more packages would define their >> faces in terms of inheritance from standard/built-in >> faces. This would mean a user could tweak the built-in >> faces to suit their preferences and the additional >> packages would inherit those tweaks without needing >> to be done individually. > > Personally, I wish fewer packages, and default > Emacs itself, would define _fewer_ faces as > inheriting from other, standard/built-in faces - > in particular from font-lock faces. > ___ > > tl;dr: > I expect that my opinion on this is a tiny minority > one. I express it anyway, hoping it might open one > or two eyes or kindle a second thought here & there. > ___ > > _Users_ can always do what you say: customize faces > to inherit from some face they want as parent. And > they can do that at multiple levels: inheritance > hierarchy as deep or broad as you like - turtles > all the way...). > ___ > > Font-lock faces, in particular, are defined to be > appropriate, by default, for particular _purposes_ > (contexts) - e.g. comments. Inheriting from them > willy nilly for faces that have nothing to do with > those purposes (e.g. non-code modes don't have > comments) creates unnecessary coupling. > > The only face that has no specific purpose/context > is face `default'. And that's as it should be. > In effect, all faces inherit from `default' (in > addition to having their own particularities). > ___ > > Inheritance can be invisible at first sight, when > trying to figure out why a face looks as it does. > > Inheriting by default is a bludgeon. That blunt > club is often touted as the _reason_ for built-in > face inheritance by default: > >> without needing to be done individually > > A false problem, IMO. > > 1. Customizing a face _should_ in general be an > individual choice, taking _context_/purpose > into consideration. (It's a similar decision > to that of defining its default appearance.) > > 2. Nothing prevents customizing a face to inherit > from another, including from standard/built-in > faces. It's _not at all difficult_ to do. > ___ > > Inheriting by default has almost the same negative > effect as defining a face to have, by default, the > same appearance as face `default' (a practice that > `emacs -Q' used to embrace, and perhaps still does > here and there): You can't tell at a glance that > there's a separate/different face there. > > Far better to use a different default appearance, > even if perhaps "ugly", so that users immediately > see that there's a separate face there that they > can customize to their liking. > > The best way to introduce users to the fact that > they can easily customize faces is to let faces > stand out individually, by default. > ___ > > I don't mean that each face needs a different > default definition. > > I mean only that, other things being equal, > identical appearance works against recognizing > the presence of a different face. > > What appearance to give a given face by default > is always a judgment call. I mean only to add > this consideration to such a judgment, as one > more consideration, perhaps too often overlooked > in a zeal to concentrate face default appearance > with predefined inheritance. > ___ > > One place _to_ perhaps use face inheritance by > default is in a theme. > > And a library can similarly have some of its > faces inherit from some of _its_ other faces - > the `vc-*' faces inherit from `vc-state-base', > for example (with the tradeoff mentioned above: > lack of immediate recognition). > > A priori, most other uses of predefined > inheritance are likely unwise/unhelpful, IMO. The big use case your argument overlooks is the one I'm forced to deal with all the time. I have very specific requirements for face colours because of a vision impairment. Emacs is a constant frustration for me because of the number of faces which are defined. For example, list-display-faces shows over 1030 faces on my system! Without inheritance, this means I have to customise a majority of those faces. I have also yet to find a theme which handles this well, though the modus themes are pretty good and life has gotten better since all the fine work put into those themes. The issue of inheritance based on faces defined for a different purpose is not a big issue and could be largely addressed by defining a good set of 'base' faces with appropriate names. However, I find this a lesser problem than the number of faces which are poorly defined and only work well if you are running in a GUI frame or use a light theme or use a terminal with 256 colour support etc. I also think the issue of inheritance causing problems because users don't realise a face inherits from another face is overstated. Inheritance is just another attribute in the face definition and is as clear as any other attribute setting. Furthermore, if inheritance was used more, users would become more aware of it and would deal with it appropriately. Having over 1000 separate face definitions seems insane at one level, but I guess it does allow the ability for users to have ultimate customisation. However, if we are going to have so many faces, there really needs to be a mechanism which allows customisation which avoids having to have 1000 set-face-* or a huge set custom face block in your init file. This doesn't have to be via inheritance, but that seems to be a workable solution until someone suggests something better. I'm sure some will suggest the problem is due to too many packages defining faces when not necessary. That may be true. However, I see lots of people requesting distinct faces in many of the packages I follow, so don't see that getting any better - in fact, I expect it will get worse as more great useful packages are added to the Emacs ecosystem.