From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: font-lock-delimiter-face - what for? Date: Thu, 29 Dec 2022 17:57:22 +0200 Message-ID: References: <361ac1e9-c1b3-824a-834b-39832a4fe2b7@yandex.ru> <12869a5f-ed38-eff4-8042-3da121f59ad5@yandex.ru> <8de4913a-f508-9acc-76ba-a2590e16f33f@yandex.ru> <010a042a-cfd5-517b-cd2a-cb797c3390e5@yandex.ru> <328c8aa9-4a5d-218e-92d0-94ca27a709ca@yandex.ru> <52efe7a5-af9d-5db6-2584-456173d46ec5@yandex.ru> <-KaE9PLXI4_nlKIMnP1AL_TwhjpJy5q8KnmZMlePPemiOPsOsoItOkl9HXHY2xIccGR6rJCiG2bDwbUW3h3D7BFYZ7Wm7fJ0Eo1VqOYfxnY=@rjt.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9784"; 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 , emacs-devel To: Randy Taylor Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 29 16:58:10 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 1pAvII-0002N7-Fl for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 16:58:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAvHe-0000pS-KC; Thu, 29 Dec 2022 10:57:30 -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 1pAvHc-0000o9-4j for emacs-devel@gnu.org; Thu, 29 Dec 2022 10:57:28 -0500 Original-Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pAvHa-0004Pw-6C for emacs-devel@gnu.org; Thu, 29 Dec 2022 10:57:27 -0500 Original-Received: by mail-ed1-x535.google.com with SMTP id s5so27192673edc.12 for ; Thu, 29 Dec 2022 07:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=DHaKzc+k6A8hbJq1bWr2P2u+4LwbhZr/guLx9rrkx6o=; b=Mk2OSj/gl3reMHtqTKm0whzLXUfPXfLTQUW8bp5IDfq25qn32EaF/zFCd/QEqqKyCD oR4jFDdie9Re7Int0h/s9qD1dO7rMnB1eei1YZ/JB9ktcqGMNcpQffumUQNSE8TT4SO6 QBiYIgbOusWaD+ivA21dv+iRGr4cVjR+80iO23cW4+EP1Hb/rtnwrEC2HeutNxsnnU/2 rO2ph8Vl517J2RoFMZX0NWavQK1b34hB3TG//J/yohBqZ+mIQX7l31hrLI9yDLhjreB3 U2FbNBIwtOURgkDRdqC8CKOFfYoRs1v37LK+dktInTlbX5UF0EKQ8DvoBpVoEOPl3q6Z xTAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DHaKzc+k6A8hbJq1bWr2P2u+4LwbhZr/guLx9rrkx6o=; b=oWKdqtfXXYTlR4sN53az7zdQC9hvJk38ONuGvWWzQkNzAeaNwdbzzNVW91EjC60Lat gx4HXTnxz2iLcHYeusLI8I/FQbWjr+vla+I+rAKet+J77SWIb9iPQjQxnVEDOXHBOmYc fegWSNXgpowfs0pyhodVYRcW1dqqifAcqMValwpLAgWhEeQNRpe3g5ggsPdL01yd7/Zo 85lYeV5s6cRs0d+2gTB6OLMFTqBWAnJtsbtlbSeG0uCP/W2mI9rmT7SbC4kSGXLskrm6 y8ISeMmomSo62hf5Ka6syXqWe43khCKg6a3RrXbu6ldAFxtcEqhXTt8I6nAQy70SCQHy iMpw== X-Gm-Message-State: AFqh2ko9q6Okj98DgWpHVkStR41wrZN9LQKV2cFDytNxpftj5gmosK9B t17GtzP4f4TcA1Z3V7jhBtWJTRPeS34= X-Google-Smtp-Source: AMrXdXvC0Dp5ZZ0nlI2EuvsGeM+rBsW/XBZoCV8EOGLCFdYInf+lBXJqom94ZUO6GaJTwYdXAYLk5Q== X-Received: by 2002:a05:6402:33a:b0:47b:2524:5cf6 with SMTP id q26-20020a056402033a00b0047b25245cf6mr24893118edw.40.1672329444638; Thu, 29 Dec 2022 07:57:24 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y26-20020a1709063a9a00b0078c213ad441sm8622717ejd.101.2022.12.29.07.57.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Dec 2022 07:57:23 -0800 (PST) Content-Language: en-US In-Reply-To: <-KaE9PLXI4_nlKIMnP1AL_TwhjpJy5q8KnmZMlePPemiOPsOsoItOkl9HXHY2xIccGR6rJCiG2bDwbUW3h3D7BFYZ7Wm7fJ0Eo1VqOYfxnY=@rjt.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::535; envelope-from=raaahh@gmail.com; helo=mail-ed1-x535.google.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.149, 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.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302038 Archived-At: On 29/12/2022 05:46, Randy Taylor wrote: >>> Then we should get rid of font-lock-punctuation-face instead. If we keep it and use it in place of misc-punctuation, then changing punctuation-face would also change the bracket and delimiter faces, since they inherit from it. >> >> >> That's usually how inheriting works, yes. >> >> Do we anticipate misc-punctuation to often have unique attributes? If >> so, it might be at least some reason to keep that face. > > It depends on the language. A few modes already make use of it: bash-ts-mode, cmake-ts-mode, and yaml-ts-mode. We should also probably use it for string interpolation characters (e.g. { and }, or whatever the language uses). They can use font-lock-punctuation-face in its place. >>> font-lock-punctuation-face wouldn't be a great name either since it's no longer referring to all punctuation (which is its current goal, and the docstring can always be updated). >> >> >> Why wouldn't it be referring to all punctuation? All attributes that are >> not overridden by bracket- and delimiter- faces will show up in them. > > That was assuming the bracket and delimiter faces would no longer be inheriting font-lock-punctuation-face. If they still are, and font-lock-punctuation-face is taking the place of font-lock-misc-punctuation-face, then changing that face also affects the bracket and delimiter faces too. Yes. > What if the user just wants misc. punctuation to be different? Do they actually want that? Suppose they do, though. If a user theme (user settings) or a named theme changes some attribute in font-lock-punctuation-face which it doesn't want to have in its descendants, they can go ahead and customize the same attribute in descendants (all 2 of them) to have a different value. Yes, that takes a little more effort. Do we anticipate this to be the common case? If we have some evidence toward that, then sure, having a separate face makes sense. And font-lock-punctuation-face's docstring should mention that it's not to be used directly. > If we want to get rid of font-lock-punctuation-face because we don't really do that parent face stuff and/or there doesn't seem to be a use for it, then I'm not against that. But I think font-lock-misc-punctuation-face should certainly stay (and can be renamed if people don't like the name and have a better idea for it). No, I wanted to keep the inheritance. Just like we have font-lock-doc-face (for docstrings) which inherits from font-lock-string-face, and both faces are used. Or font-lock-comment-delimiter-face inherits from font-lock-comment-face. Or font-lock-preprocessor-face inherits from font-lock-builtin-face. Etc.