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: Automatic face setting based on contrast? Date: Sat, 09 Oct 2021 12:45:17 +1100 Message-ID: <87czofvt9z.fsf@gmail.com> References: <87k0iub53g.fsf.ref@yahoo.com> <87k0iub53g.fsf@yahoo.com> <87tuhswcfw.fsf@gmail.com> <837deoype3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.0; emacs 28.0.60 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 09 04:15:38 2021 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 1mZ1ti-00087G-Jm for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Oct 2021 04:15:38 +0200 Original-Received: from localhost ([::1]:39868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZ1tg-0000Gl-Ac for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 22:15:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZ1sn-00081j-77 for emacs-devel@gnu.org; Fri, 08 Oct 2021 22:14:41 -0400 Original-Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]:46062) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mZ1sl-0001YK-IP; Fri, 08 Oct 2021 22:14:40 -0400 Original-Received: by mail-pg1-x529.google.com with SMTP id q12so4080429pgq.12; Fri, 08 Oct 2021 19:14:38 -0700 (PDT) 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=VxCjG6JBUUMIb4OfeFVIcQcBm0b9DNt79GfTbRzdrBY=; b=TwZnqVfQ97Iyt4KAFyCjlXh8eIyvAaHq9aF7U0fMrGilN0JQClkLTapZA+5M872KFa Q3y6nNa+By/djyP2YZXggs6WyGipz1gw1Smvfi9aVJpTLiLGoewsmmOa6UxN/ZqpS0Ed sRMl4AlJcOZWm75aTlarhi2eGuOkbL9cbX0vtWYmH7VEWIaN8+6nMBiR5svdMgQc5oXx 6Z18kc6M2L9k/t9VFwsbNdD3IwpQ3UpbIZePkQmJn2jixGobFCC6gdJ3j105uNAk2r9n tCxWSOijxhbLNeDNVcyfrnCw6eoaHSIt4Nwb9MTnPiyMgvkgHXzF7y804NFTODgwdRm1 ktUA== 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=VxCjG6JBUUMIb4OfeFVIcQcBm0b9DNt79GfTbRzdrBY=; b=rXQ+8naVBAnI+uF692mNZZhnOZfg4EK6QLvnmzrgpUGUXSJbXTYQjNa8ofTa8KO9+1 j442cYXfWmFNTUQvBmdC4lzHnXm+bKW7IivYQT61AtXkBiwU5JTDWxGI+qPUBan7ZGvP 7IPzYAE7LEq6yyiW0Rvp5JdGUFbTq5heG70tEGcnJGG+qBj2/CjyJxUW6mEc2EvppX61 gFbj8kGeJBAzJw1MngwqSr8JSje8qgqdcyGG0m9T3xfDih7vUOSN3+F+LcKvaeDV+JoF 7nx1c49rle8lZqpqLFjiU12mNZsRKsv8xaruXq+fbUJRF+X5ChyPyIqXRCCqe8+x4ADj Ol/Q== X-Gm-Message-State: AOAM531vAXySo2SbQOyNgkWZjJ/sMZK1zq/+FRjO3h2dwWlREUjuNJH4 GUpE+4/5X6QPbow8oBvXrVIuNO7eBRU= X-Google-Smtp-Source: ABdhPJzvBE2DomzrBj1cfT5mo7TXfRuZXkuklfm7Nw1WNP6C38CT7/2FsFf6lYkdx2WYKJgQ3DoCFg== X-Received: by 2002:aa7:9f46:0:b0:44c:7912:9b2e with SMTP id h6-20020aa79f46000000b0044c79129b2emr12920087pfr.11.1633745676732; Fri, 08 Oct 2021 19:14:36 -0700 (PDT) Original-Received: from tim-desktop (203-59-51-76.dyn.iinet.net.au. [203.59.51.76]) by smtp.gmail.com with ESMTPSA id ls7sm437617pjb.16.2021.10.08.19.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 19:14:36 -0700 (PDT) In-reply-to: <837deoype3.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::529; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x529.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:276583 Archived-At: Eli Zaretskii writes: >> From: Tim Cross >> Date: Fri, 08 Oct 2021 11:49:06 +1100 >> >> Over the years, I've seen a considerable growth in the number of faces >> defined, which has made consistent definitions of themes somewhat >> challenging. Running M-x list-display-faces on my system shows over 1100 >> face definitions, which seems excessive. > > In "emacs -Q", I see only 114 faces in that display. > which makes me wonder why so many packages feel it necessary to add new faces rather than just leverage off the 'default' faces. Would not be as challenging if all those additional faces defaulted to inherit from one of the 114 'default' faces, but unfortunately, many don't. >> While many of these do use >> inheritance, many don't. This is unfortunate. It would be great if all >> modes which define faces by default inherit from one of the semantic >> font lock faces, allowing basic theme definitions to be possible by just >> tweaking the much smaller number of semantic faces and leaving tweaking >> of mode specific derived faces to the user when desired. > > I think tweaking 100+ faces is not much easier than tweaking 1000. > Both border on the impractical. > Agreed. However, not all of those 114 are 'semantic' faces. If the default for each non-semantic face was to inherit from the semantic faces, then most themes would be able to be defined via setting the handful of semantic faces and leave more specific customization to the end user who want to tweak the them in some manner. >> It would also be useful if there was some way of listing the defined >> faces which showed which face they are derived/inherited from to make it >> easier to see exactly what would be affected if you modify the 'parent' >> face and which faces are not defined to inherit from one of the semantic >> faces (and could be a possible candidate for redefining to inherit from >> a semantic face). > > That sounds like a simple Grep job to me. > Hmm, not sure it is that simple given grep is line based and face definitions can be spread over multiple lines. However, once you have gathered the list of faces, it wouldn't be too hard to iterate over them to extract which ones are inherited. What I was thinking of was a display which would show the inheritance hierarchy, possibly in some sort of tree form to give an overview so that you could not just tell which faces inherited, but where they inherited from. In some respects, the ability to add new faces is possibly a little too easy and has encouraged an over proliferation of faces. This makes consistent theming much harder than necessary. > Eventually, I don't think there's a good solution to color contrast > that relies on manual tweaking of the faces. I'm not convinced there is a good automatic solution which won't also need some manual tweaking, especially given how quickly the number of faces blows out once you add some additional packages. While automatic contrast setting can help, manual tweaking will still be necessary. Consistent use of inheritance from the core semantic faces would make this easier. One challenge with automatic contrast setting is that it has no way to take aesthetics into account - you can get high contrast colours which are simply unappealing. This is still better than the current situation when you unexpectedly come across a face which is unreadable because it has not been set to a suitable contrast for the current theme. This would be less of an issue if all these additional faces inherited from the core semantic face by default. The code to ensure adequate contrast would then only need to consider those semantic faces.