From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Randy Taylor Newsgroups: gmane.emacs.devel Subject: Re: font-lock-delimiter-face - what for? Date: Thu, 29 Dec 2022 18:41:14 +0000 Message-ID: References: <361ac1e9-c1b3-824a-834b-39832a4fe2b7@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 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11697"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 29 19:59:25 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 1pAy7h-0002rq-IN for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 19:59:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAxqY-0007jf-OH; Thu, 29 Dec 2022 13:41:42 -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 1pAxqX-0007ic-8A for emacs-devel@gnu.org; Thu, 29 Dec 2022 13:41:41 -0500 Original-Received: from mail-4018.proton.ch ([185.70.40.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAxqU-0006TQ-BN for emacs-devel@gnu.org; Thu, 29 Dec 2022 13:41:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1672339287; x=1672598487; bh=+zMtOgl4eWok3tcvcmD+JxWoLjY5STQ4BP35ZTKjHdA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SsGfntmSfvObMBiqt4LOKsjtdphghYlTxhslfY/YPagVmQg92dAt7hhX4ZfbUbZm6 ofSf10d4j9aTQmRkbqnMcq5fD5m0r1ruwFh5y3EIYOVXpSp3Jad1pK7i9Ojw8E7jhp jsGVTNpGLGqyHgFVy5KY3eMFSbtxRoXXHFCR207BRNs7KnSdJ6P5e/qOg91EKzGiTM 4vu4te9w6DqdGJhrKqZKx3ZabbY1retA6lnLQf0xjYF3pm1i4XyEXtBfnJUxHqS2Pn XcYrcCtqzrciz2XdOim3jb72VViKkfS8P1cYmcR3dp1Ejm7aObpV/QNZkXbSN9qo6V PJIadjso3D44g== In-Reply-To: Feedback-ID: 44397038:user:proton Received-SPF: pass client-ip=185.70.40.18; envelope-from=dev@rjt.dev; helo=mail-4018.proton.ch 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, SPF_HELO_PASS=-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:302057 Archived-At: On Thursday, December 29th, 2022 at 10:57, Dmitry Gutov = wrote: >=20 > On 29/12/2022 05:46, Randy Taylor wrote: >=20 > > > > 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. > > >=20 > > > That's usually how inheriting works, yes. > > >=20 > > > Do we anticipate misc-punctuation to often have unique attributes? If > > > so, it might be at least some reason to keep that face. > >=20 > > 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 use= s). >=20 >=20 > They can use font-lock-punctuation-face in its place. >=20 > > > > 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 t= he docstring can always be updated). > > >=20 > > > 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. > >=20 > > That was assuming the bracket and delimiter faces would no longer be in= heriting font-lock-punctuation-face. If they still are, and font-lock-punct= uation-face is taking the place of font-lock-misc-punctuation-face, then ch= anging that face also affects the bracket and delimiter faces too. >=20 >=20 > Yes. >=20 > > What if the user just wants misc. punctuation to be different? >=20 >=20 > Do they actually want that? >=20 > 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. >=20 > 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. I don't know about common but there's certainly a use case. I would say eve= n more so for misc-punctuation than the others because special symbols can = fall into that category. To me it doesn't make sense to have font-lock-punctuation-face be inherited= by bracket and delimiter and also be used for misc. punctuation purposes. = Misc. punctuation is a distinctly separate category IMO (especially since i= t has a corresponding tree-sitter feature for syntax highlighting). I added= font-lock-punctuation-face primarily to control all of the different kinds= of punctuation (same as what the previous Emacs tree-sitter dynamic module= did). Whether or not we want font-lock-punctuation-face as the parent face of all= of them (or get rid of it entirely) I don't know. I'm not sure how likely = it will be to customize all punctuation as opposed to specific kinds, but I= reckon it will probably be quite rare. We can always add it back in later = if we're wrong. Or just leave it all as is (and we can certainly improve it= s docstring).