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.bugs Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Date: Sat, 25 Nov 2023 02:21:42 +0200 Message-ID: <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@gutov.dev> References: <87y1ewgnn7.fsf@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="19905"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Andrey Listopadov , 67246@debbugs.gnu.org To: Wilhelm Kirschbaum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 25 01:23:21 2023 Return-path: Envelope-to: geb-bug-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 1r6gS7-000500-LC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Nov 2023 01:23:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6gRo-00067w-6W; Fri, 24 Nov 2023 19:23:00 -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 1r6gRm-00067j-H2 for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 19:22:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r6gRl-0006TV-Rx for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 19:22:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r6gRq-0002wv-8R for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 19:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Nov 2023 00:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67246 X-GNU-PR-Package: emacs Original-Received: via spool by 67246-submit@debbugs.gnu.org id=B67246.170087172511274 (code B ref 67246); Sat, 25 Nov 2023 00:23:02 +0000 Original-Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 00:22:05 +0000 Original-Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6gQs-0002vk-9z for submit@debbugs.gnu.org; Fri, 24 Nov 2023 19:22:05 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:54529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6gQn-0002vA-Ez for 67246@debbugs.gnu.org; Fri, 24 Nov 2023 19:22:01 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 34B6D5C01D3; Fri, 24 Nov 2023 19:21:47 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 24 Nov 2023 19:21:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8 HkgpxZlY=; b=jacrR18WAek2/qwqRgciF+YT1e6FkKTAGIPZLk356cYCnqBZxpx vQvdRfkRfs9b71xt8aOYsinRSPBCPUrG7ls54ytxxWs1y01wd0xpF5zziIupHI/P Tn55t2qLjTID1Bqgq4hIHS1qdAYs+n3KNy3iJueEABfV40nZ+6Jemy8pXnjAxCo6 wE9OKwA1y2nvH6zglJsqaxUMJHROnm8+0pfT1q5cWo/3bpTx8dXtS+qGREcDYADD wZojEZURECpoQzZUz/IXNA2OXe4c5+OUMMmmfxYgqcPk47lEXBPX8L6nl1lkDQp1 e5o4nTZCMDku/rT4h2FS7uy3+1TYu+266Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8 HkgpxZlY=; b=2KNzSsQHwnRj4CUAfowgNT/ZDL3bA/iUCF/OLsN8O6VMP72+VFK GTx4Hh21Yy924bn5gOKx3fJBKo/VXED/1xOq+dxwMP0itzM+jm4GSkUUZ5PMhrr9 wEpaM8xaUPMOF8Vu/5QaKKlGgKBdAcs3d+q5UBnGAPGnaaqVbvqNQieRUL9rMKSl 47KlY09WkVyKbZZE18E7qse47d7esEg19uUI0bwIcO5zZny5C/rkrk6yJ2gmafFK UXyU+Ht3LyXR4MwY7kSTGsR4swWWw/kHv/WyuEhJlrCJevRBvL6BQIsCNNZu2kzd JOCZihH2VIIFoGLv+s0C4CaMLlw3S2iTL/Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehiedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepjeejhfehvddukedvjedtgfeiveevgeeghfetkeehkeelieefffffgfekgfdu tddvnecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhgvugguihhtrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhih sehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 19:21:45 -0500 (EST) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274901 Archived-At: On 24/11/2023 21:47, Wilhelm Kirschbaum wrote: > I see that the latest work > (https://github.com/wkirschbaum/elixir-ts-mode/pull/36 > ) anticipated at > least some of my comments. > > Remainder: > > 1) font-lock-variable-name-face is intended for declarations and > perhaps > initial assignments (where it's also an implicit declaration), but for > other variable references it's better to use > font-lock-variable-use-face. With my test file, I see examples to the > contrary, even though some attempt to use the latter face had been made > (inside the 'elixir-function-call' feature's query). > > > Thanks, this has been fixed. Sorry, is there a specific commit in the upstream repo I could look at? > 2) Moving highlighting of function calls and variable (and/or property) > references to the 4th feature level. Looking at your font-lock > rules, it > seems like the elixir-function-call matches is more targeted than the > elixir-variable one, but still the other built-in modes put both at 4, > so it would be good for uniformity. Function definitions (and variable > definitions/declarations, if they're highlighted separately) can remain > in the 'declaration' or 'definition' feature which is put in a lower > feature level (e.g. ruby/js/typescript modes have it on level 1). > > > Level 4 is strange to me, because the default is 3.  I read the docs and > tried to > follow it with the new changes, but was hesitant to remove much from the > highlighting as not many people might discover there is a 4th level. > Then again, if there is a query it > is pretty easy just to communicate this. The idea was to balance the new look between the "old" major modes and the newer, shinier ones. So that the overall style still somewhat appeals to the existing audience, just with added features and more precision. Here's a Reddit recent thread about the same sentiment: https://www.reddit.com/r/emacs/comments/18152qo/overcolorization_everything_is_purple/ It discusses a post written by Andrey, BTW. One could basically say that a function call and a properly lookup are easy to distinguish from glancing at the text, there's not much need to highlight them. As opposed to e.g. implicit variable declaration or function declaration. And here's another aspect: the default built-in theme doesn't distinguish many of the faces (and the same is true for many other built-in themes). E.g. it doesn't distinguish variable-name-face from variable-use-face or function-name-face from function-call-face. So if the -use- and -call- are used freely, in the default setup they will get muddled with the function and variable declaration. OTOH, if the user installs a theme which has this more advanced support for the new faces (or customize the faces manually to be distinct), they might as well set treesit-font-lock-level to 4, that's very little extra effort. > Something else I would recommend: > > 3) Removing the '-face' suffix from the face names. This is the best > practice across most modes, and it's something the manual entry for > 'defface' recommends: > >    You should not quote the symbol face, and it should not end in > ‘-face’ (that would be redundant). > > Face names inside font-lock.el are a historical exception (and we > followed it when adding new faces recently), but if you search for > 'defface' inside the Emacs codebase, such names are in the minority. > > > Okay thanks, I had a look and it makes sense.  I see a new mode with the > same -face suffixes. > The defface docs does not mention this, so might be a good idea to add > it there? Probably. I rarely read the manual myself, and this is useful information. > I am not entirely sure what "you should not quote the symbol face" means > wrt to the changes, because > it does not look like I am quoting it. Indeed you're not, I only put that in the quote so that the sentence is not cut off from the beginning. Sorry if that was confusing. > I haven't done too much testing myself. Perhaps Andrey will take the > upstream version for a spin. Or we'll wait for the changes to be merged > here and continue. >