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 03:46:43 +0000 Message-ID: <-KaE9PLXI4_nlKIMnP1AL_TwhjpJy5q8KnmZMlePPemiOPsOsoItOkl9HXHY2xIccGR6rJCiG2bDwbUW3h3D7BFYZ7Wm7fJ0Eo1VqOYfxnY=@rjt.dev> 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> 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="31264"; 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 04:48:01 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 1pAjth-0007rW-4o for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 04:48:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAjsl-0006oA-Qz; Wed, 28 Dec 2022 22:47:03 -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 1pAjsk-0006nx-RK for emacs-devel@gnu.org; Wed, 28 Dec 2022 22:47:02 -0500 Original-Received: from mail-4323.proton.ch ([185.70.43.23]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAjsh-0004fc-9D for emacs-devel@gnu.org; Wed, 28 Dec 2022 22:47:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1672285616; x=1672544816; bh=C/8Psdacy8ezRnMaF5J5+Sy1g93pF2TEFA4l/VgupFo=; 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=MrMWpAlT/JD+M/hN8hZDzEFVn5/llGvfnEuX9JmCWCH+1Ap2jGrmFwBjLSH4oDQ+a lQArU0kBml3Xzf2p9L7NB/wmOymxLb2Y0pDyL1iEbGJ0lIpxIbze2/7aOmmbA4FH7O JIKAtEj0Pu1qSVzwTfV1U+2syzJu/TCpRnqkVWjuccN3PgjTT8IZiuFxgGFM3CPFYg xQN+Ce3m6PTVDcpsTNNRCMNm2MMpFuVA5HjyIHV7mtADwa0XGfeqaTe3aC3vY7pDn5 3p/23+D95R3LuiVv9wuS3gnV+Fe0BIXbBrcag1/JDDkUD66jsphcGgpHVMaTMkgoAm b9SihaPk0wGhQ== In-Reply-To: <52efe7a5-af9d-5db6-2584-456173d46ec5@yandex.ru> Feedback-ID: 44397038:user:proton Received-SPF: pass client-ip=185.70.43.23; envelope-from=dev@rjt.dev; helo=mail-4323.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, RCVD_IN_MSPIKE_H2=-0.001, 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:302022 Archived-At: On Wednesday, December 28th, 2022 at 13:32, Dmitry Gutov = wrote: >=20 > On 28/12/2022 19:06, Randy Taylor wrote: >=20 > > On Wednesday, December 28th, 2022 at 10:13, Dmitry Gutov dgutov@yandex.= ru wrote: > >=20 > > > Maybe it would be better to remove font-lock-misc-punctuation-face, t= hough? > > >=20 > > > People can still use font-lock-punctuation-face for everything > > > punctuation-like that doesn't match the category of "brackets" or > > > "delimiters". > > >=20 > > > Just like font-lock-doc-face inherits from font-lock-string-face, or > > > font-lock-comment-delimiter-face inherits from font-lock-comment-face= . > > >=20 > > > We don't seem to have a practice of "parent faces" which are otherwis= e > > > unused. font-lock-punctuation-face's docstring doesn't suggest this k= ind > > > of purpose either. > >=20 > > Then we should get rid of font-lock-punctuation-face instead. If we kee= p it and use it in place of misc-punctuation, then changing punctuation-fac= e would also change the bracket and delimiter faces, since they inherit fro= m it. >=20 >=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. It depends on the language. A few modes already make use of it: bash-ts-mod= e, cmake-ts-mode, and yaml-ts-mode. We should also probably use it for stri= ng interpolation characters (e.g. { and }, or whatever the language uses). >=20 > > font-lock-punctuation-face wouldn't be a great name either since it's n= o longer referring to all punctuation (which is its current goal, and the d= ocstring can always be updated). >=20 >=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. That was assuming the bracket and delimiter faces would no longer be inheri= ting font-lock-punctuation-face. If they still are, and font-lock-punctuati= on-face is taking the place of font-lock-misc-punctuation-face, then changi= ng that face also affects the bracket and delimiter faces too. What if the = user just wants misc. punctuation to be different? They should all be separ= ated IMO. 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, th= en 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).