From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.help Subject: Re: Introducing face in comments for various modes Date: Mon, 12 Dec 2022 11:50:52 +0100 Message-ID: <009361a1-4430-ac3a-f395-ce32f10b31f2@gmail.com> References: <9ZK1Solghrmps4AarUsz2E6-mAdkrTZoXPs4RTRTd9sZ0Cd8DGhK955im1kuug-EZXU3tc5rgDDd16vQexxpFnMvMFjFqnNnh0noashyLdE=@protonmail.com> <0RJB0bPRTMAqXlUbL2kGUvJtnCNPYwPhqTNi_l9nIpQAciTZYcYCikFVqi2Nr_UZLbT1_DRtX8G0dSkgI4jln5DTYBDxLz4i7L2d9wx-kA8=@protonmail.com> <21708ec2-d908-4e91-6c0a-4b1cd253e707@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33196"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: Stefan Monnier , help-gnu-emacs@gnu.org To: Heime Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 12 11:51:38 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1p4gPK-0008Te-Jw for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 11:51:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4gOj-0002BO-4e; Mon, 12 Dec 2022 05:51:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4gOh-0002B2-Kl for help-gnu-emacs@gnu.org; Mon, 12 Dec 2022 05:50:59 -0500 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4gOe-00076N-A4 for help-gnu-emacs@gnu.org; Mon, 12 Dec 2022 05:50:59 -0500 Original-Received: by mail-wr1-x42c.google.com with SMTP id m14so11614816wrh.7 for ; Mon, 12 Dec 2022 02:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Go69o+m/ehANTAv3sVv5kNbPnohUTpVAt9QfbxHx+r0=; b=AU1MER4c0OPoifZ+ruxMqH48FDquZwETEvsnONjRq05LFI8Vtm7iTssgKW2BaIKp+Q yAdvlIaf1YPRN8Ln2rHNsxOvdaS/ejJ7uxlqn6rrCCGA7BnO4qRKFVHYR24oLrMdqxIr wneWdaWb7hZo6W4de/yoWQho04r9m/staSrBInjmKv6f1PU2ML1zmUpax76EOyq3psX8 pE7lk1Zs5ZJIeXGfWQoIMztxFNddHKqji46SqC8YrsagGDEv6mPgoPhTCn4Tm59RTG/S IuTEFwia5LeleKc0iUS//9QgMlJySNyJp1+drscmYX94w7OVj3fOMhvE4AAaEArbBgWl ayMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Go69o+m/ehANTAv3sVv5kNbPnohUTpVAt9QfbxHx+r0=; b=O08dflUrHWEubS4tcq9jMoGLCbUy4uILHzCrlBKTA7vTxqVZdV3zZR5SnC6UgjDy4+ V1yXm6Bj/EF9M+/SNBQkJR+skD9HmWJRBZAm4B9jZtC/rNCsplLgz4tynOmX1fQsoGTc STpxLwV2febnJvgJgWdCpCwUkvK1VsGW2q1MxYA6RcW4zEzM4aKtXWr74PcjdUK1pksf dMiQX9gOctWL5ZOaHZj7XK9EFUxg2crr5N1vzVGMh6p5mVQsDwx4rFRS5fu7PsY3q2RH mmDi961oeb1Dp34DZwDORn6wk9xhcc4s2XpOV9xVtEhShrpiQfq6CN1oZgR3vzJHCo21 FROA== X-Gm-Message-State: ANoB5pnAeQu1FlH8O9G92gyZrfaxFoF/ZYkOYXMQ4fArNeq0hLSqthsb SUjP7K4rLo31Dk/qgay3E98= X-Google-Smtp-Source: AA0mqf42iv8vxYRY84KEcV4qXRSflgj2A3U0466e38JTgXW44EAKncOcDpLaMRLkpcAaRUdcDMk6qQ== X-Received: by 2002:a5d:5f0a:0:b0:242:72ec:eb34 with SMTP id cl10-20020a5d5f0a000000b0024272eceb34mr10645953wrb.14.1670842254415; Mon, 12 Dec 2022 02:50:54 -0800 (PST) Original-Received: from ?IPV6:2001:628:2010:4094:29f:ef59:b326:7dad? ([2001:628:2010:4094:29f:ef59:b326:7dad]) by smtp.gmail.com with ESMTPSA id b4-20020a5d4b84000000b00236c1f2cecesm10350932wrt.81.2022.12.12.02.50.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Dec 2022 02:50:53 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=thibaut.verron@gmail.com; helo=mail-wr1-x42c.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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:141671 Archived-At: On 12/12/2022 11:20, Heime wrote: > ------- Original Message ------- > On Monday, December 12th, 2022 at 9:58 AM, Thibaut Verron wrote: > > >> On 12/12/2022 10:21, Heime wrote: >> >>> ------- Original Message ------- >>> On Monday, December 12th, 2022 at 8:49 AM, Thibaut Verron >>> thibaut.verron@gmail.com wrote: >>> >>>> Le lun. 12 déc. 2022 à 04:01, Heimeheimeborgia@protonmail.com a >>>> écrit : >>>> >>>> ------- Original Message ------- >>>> On Monday, December 12th, 2022 at 2:24 AM, Heime >>>> heimeborgia@protonmail.com wrote: >>>> >>>>> ------- Original Message ------- >>>>> On Sunday, December 11th, 2022 at 5:40 PM, Stefan Monnier via >>>> Users list for the GNU Emacs text editorhelp-gnu-emacs@gnu.org >>>> wrote: >>>>>> BTW, there is a related convention in ELisp code where >>>> comments that >>>>>> start in column 0 and which are introduced with 3 or more >>>> semi-colons >>>>>> are considered sectioning headers (where ";;;" means a top-level >>>>>> header, ";;;;" a subheader, ";;;;;" a subsubheader, ...). >>>>>> >>>>>> I'd be happy if Emacs were changed to highlighting those. >>>>>> >>>>>> Stefan >>>> If you are colourising "Sectioning Headers", ensure that vibrant >>>> and good contrast: >>>> >>>> 1) betweenthe text and the background; >>>> >>>> 2) and between a header, subheader, subsubheader, ... >>>> >>>> Use some colour metric (e.g. using the Web Content Accessibility >>>> Guidelines [WCAG]). >>>> >>>> Because I consistently see that developers almost never care (or >>>> have the skills) >>>> to properly set up colours. Have suggested changing the colour >>>> scheme as described, >>>> for "Org Headings" because they are indistinguishable against a >>>> dark background and >>>> between a heading and its subheading. Applying such metrics have >>>> been turned down, >>>> with the excuse that if I want them right, I have to work on >>>> emacs customisations >>>> myself, as the crappy colours are there to stay. >>>> >>>>> The colors of the standard themes are chosen with its (light) >>>>> background in mind. If you change that background, it is not >>>>> surprising that things fall apart. >>> Choosing colours with a light background in mind is the wrong approach >>> because colours produce far greater visual >>> impact. >> >> There is no right or wrong approach, but individual preferences. > Standard metrics exist. The Gnu Project like many others, does not > want to use them. You're moving the goalpost: the sentence I quoted claimed that "focusing on a light background is the wrong approach". It's also factually not true that the GNU project does not care about readability metrics, especially now that the Modus themes are shipped with Emacs. >> If you want a dark background, just use a dark background theme. For >> instance, emacs has a built-in implementation of the tango dark color >> palette. If contrast if your primary concern, you should look at the >> modus themes (modus-vivendi for the dark background), which is also part >> of emacs now. >> >> M-x customize-themes and make your choice. > If you use "modus-vivendi" for org-mode, the colours are all almost white, > a big problem particularly when you fold the org headings. I don't like dark backgrounds, but it seems perfectly readable to me. Anyway, from personal experience the developer of the Modus themes is extremely responsive. If you have a problem with his themes you should take it up with him. >>> Rather, there there should be carefully chosen colour settings for >>> both light and dark backgrounds. >> >> That's how you end up with settings which are at best acceptable, but >> not perfect, for both light and dark backgrounds. The range of colors >> which are suitable for both light and dark backgrounds is just too narrow. >> >> The proper way is the current way: carefully curated themes implementing >> all colors in a consistent ways. > > What metrics are being used. The blind belief that the proper way is the > current way, is the origin of the problem. For one, the Modus themes were developed with quantified metrics (minimal contrast ratio afaik), and they are two completely different themes for black and light backgrounds. If you think you can do better, you are welcome to try. But if you come and claim that the current way is the wrong way, the burden of proof is on you. :) > >>>>> It is not a new problem, but it doesn't mean that you have to >> customize all the individual faces yourself. Instead, you should look >> for a theme implementing >> >>>>> the colors you like, and install it. The responsibility for having >>>>> consistent colors across all emacs fonts is on the theme designer. >>>>> You can still tweak some >>>>> faces from there if you choose to of course. >>>> At any rate, Stefan's suggestion would not require making new design >>>> choices, as there are already faces designed for fontifying headers: >>>> outline-1, outline-2, etc. >>> Making a new design choice is a necessity if you want to move forward. >> >> No. The question is whether to fontify those headers, how to identify >> them, etc. >> >> That's completely separate from the question of changing the face >> currently used for headers in other places. >> >>>> Those faces are used by outline-mode, but not by outline-minor-mode >>>> (which emacs-lisp-mode uses to implement the ;;; comment headers) at >>>> the moment. >>> Which proves my point that changes are necessary. What needs to be >>> done is for colour contrast metrics >>> to be taken seriously by all packages, rather than relying on some >>> theme to fix the crappy default choices. >> >> Sorry to be blunt, but you couldn't be more wrong. For a start, >> outline-mode and outline-minor-mode are the same package. :) >> >> But more to the point, with the current system, packages choose existing >> faces to implement coloring based on what they should color (e.g. is >> it a comment, is it a header, is it a keyword, is it something >> important). And the theme designers choose colors (and other features) >> for those faces. >> >> As a result, colors are the same across all of Emacs (for example >> comments look the same in elisp and python), and -- if the theme maker >> is competent -- the colors will implement good contrast and be readable >> everywhere. > One can at least use good metrics for light (white) and dark (dark) background. > We have not even arrived at that yet. I am not arguing against comments looking > the same, but that there should specific settings for the canonical white and > black background as minimum. And I am telling you that there are. For light background: the default theme, leuven, tango, modus-operandi For dark background: the default theme with inverse-video, tango-dark, modus-vivendi >> If instead we were to let each package decide on its colors, Emacs would >> look like a Christmas tree with different colors all over the place. And >> most of them would be really crappy because the package developer was >> never trained in graphic design, or because they didn't plan for all >> possible background colors (it's not as simple as light and dark, some >> people use blue, or green backgrounds), or because they didn't predict >> that their choice of color would conflict with the choice made by a >> minor mode in another package, or... > Am only discussing for white background and black background, which are the > canonical settings for printing. With colour contrast you are limited by > the metric values which limits to about eight colours. > It is not Christmas Tree as you say. Focusing on any possible colour combination > (blue, or green backgrounds) is beyond the scope of my discussion. No it's not. My point is that if you leave the responsibility of choosing colors to packages as opposed to themes, it will be a Christmas tree and there will be unpredictable combinations. It's a direct consequence of your idea, you can't just wave it off. It's already bad enough now with some packages defining their own faces without at least inheriting from the standard ones. There are currently 5330 packages on Melpa. Do you plan to contact the authors of all of them individually to get them to implement your preferred colors? With the current approach, on the other hand, it's very easy: report a bug for the theme you're using, or make your own theme if you really want to. >> You shouldn't think of themes as "fixing the default choices" >> (especially considering that you are the one "breaking" them by >> insisting to use them with a background they weren't designed for). >> Their purpose is to implement different choices in a consistent way. > Good design in much more important that consistency. It's also much easier to achieve in a consistent system. >>>>>> Heime [2022-12-11 15:35:41] wrote: >>>>>> >>>>>>> The following uses `hi-lock` to change the foreground of >>>> comments matching >>>>>>> a regexp. This is implemented for emacs-lisp files where >>>> comments start >>>>>>> with ";;". >>>>>>> >>>>>>> I would like to extend this for other programming languages >>>> besides emacs-lisp >>>>>>> files, using the relevant comment character automatically >>>> for that language. >>>>>>> (defface elfa-face >>>>>>> '((t :foreground "magenta")) >>>>>>> "Face for comment headings.") >>>>>>> >>>>>>> (defun elfa-regexp (&optional actm) >>>>>>> "Identify comment category ';; [Category]'." >>>>>>> (highlight-regexp >>>>>>> "^;;\s+\\[.+\\].*$" 'elfa-face)) >>>>>>> >>>>>>> (defun elfa-category () >>>>>>> "TODO." >>>>>>> (interactive) >>>>>>> (add-to-list 'auto-mode-alist '("\\.el\\'" . hi-lock-mode)) >>>>>>> (add-hook 'emacs-lisp-mode-hook 'hi-lock-mode t) >>>>>>> (add-hook 'hi-lock-mode-hook 'elfa-regexp))