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, 18 Nov 2023 03:36:26 +0200 Message-ID: References: <87y1ewgnn7.fsf@gmail.com> 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="35004"; 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 To: Andrey Listopadov , 67246@debbugs.gnu.org, Wilhelm H Kirschbaum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 18 02:37:28 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 1r4AH1-0008u2-A1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Nov 2023 02:37:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4AGe-0005ta-Na; Fri, 17 Nov 2023 20:37:04 -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 1r4AGc-0005tL-Et for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2023 20:37:02 -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 1r4AGc-0008IY-6x for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2023 20:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r4AGc-0003kR-Dq for bug-gnu-emacs@gnu.org; Fri, 17 Nov 2023 20:37: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, 18 Nov 2023 01:37: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.170027140214380 (code B ref 67246); Sat, 18 Nov 2023 01:37:02 +0000 Original-Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 01:36:42 +0000 Original-Received: from localhost ([127.0.0.1]:47334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4AGH-0003jr-Lh for submit@debbugs.gnu.org; Fri, 17 Nov 2023 20:36:41 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:50785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4AGE-0003jd-CY for 67246@debbugs.gnu.org; Fri, 17 Nov 2023 20:36:40 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3718D320090D; Fri, 17 Nov 2023 20:36:31 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 17 Nov 2023 20:36:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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=fm2; t= 1700271390; x=1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl 4u6ICPdw=; b=rtbMOQQ5vu++oA6TYe13Bgwc7nrYGkdIgMicnNylh28mee2iZ3/ EDbMk6Z4wu5ONFx85x4nx1OkrumloXzLqv3oX0FpXHtUgbpBFk5d2a7Dd+8jr4MW osrFIOpdjG3jgwnOYqMEfh+ApFcDQRyPBXRCLNhQbNb3PxWkP9iGyTMpnchjR0jZ BrtrLg+01UMLW42wOGoo/UxR3MsmoZYVoTpjzM6TqADDNcM8vW7xFtbkpkeL7DFI P7uHoGnO+hZZ3XAfPiDNOnY8w6LQUoGwmBVHXoW2fixVJSANEBvflJSzIZVYYqSq 9DgzNq3ePQcH9UEikS+v9CqDr8O9YO0zxbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1700271390; x= 1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl4u6ICPdw=; b=1 SSOtxtsuOW8pskT8v7GIOBQnB3Ka2sczboyWl76ULbl2iGMYl69skylGReIvRMqZ s6uN6eLCpFKCsZhxY6oMDE+AAKBj/WWd344HRxFT3vAztVT7eOSKE46CkeBhgPZP 4gzYXFIrILwweCEGrU8Q2AwNYJKQJ4Y6ypLoNiaPrCCobussQpZBu0B12/qo1cPN fqyYFtasdMxaHkgzlgX0ioGJgBpxPPKS3/dJBQ2gvO7JQ/Ixlch+voboyiJnhYdt R1oZkYew4sHdWZ27zVZHxx9eXLZgMOceqmCdQn5BqKEM0tVuUZtbCBPIucwreCvo KQjyA8dG6eSTpL4tNmE/w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeguddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Nov 2023 20:36:29 -0500 (EST) Content-Language: en-US In-Reply-To: <87y1ewgnn7.fsf@gmail.com> 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:274524 Archived-At: On 17/11/2023 21:50, Andrey Listopadov wrote: > > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the > latter uses faces rather inconsistently. > > For example, the =font-lock-keyword-face= is used for both keywords and > method calls, as well as for parentheses. The > =font-lock-function-name-face= is used both for function definitions, > parameter names, and calls. Some calls use the > =font-lock-keyword-face=, for example the call to `raise'. The > =font-lock-type-face= is used both for types and =:symbols=. > > All of that basically makes Elixir code mostly use 2 colors. > Additionally, it makes impossible selectively disabling highlighting, as > disabling the function call highlighting will disable the function > definition highlighitng an so on. > > I believe, Emacs 29 introduced a lot of faces for all kinds of > situations possible in Tree-sitter generated AST, so perhaps the fix is > to use them more semantically, rather than for good looks. Thanks for the report. Wilhelm, could you look into this? If you have time. Speaking of new faces, we added font-lock-function-call-face that can be used for function calls, while font-lock-function-name-face stays used on definitions. For parens, if one wanted to highlight them at all, font-lock-bracket-face could be used. Though it's probably better to leave them to the 4th feature level (see js-ts-mode as an example). elixir-ts-mode currently defines 3 levels. For levels, we've currently settled on the scheme that function calls and property lookups go to the 4th level of highlighting, whereas the default is 3. This is all tweakable by the individual user, but I think it's better to stay consistent between the modes. Finally, I see that font-lock-function-name-face ends up being used for parameters (as Andrey mentioned) and local variables as well. That's not great; probably a query that ended up matching too widely. We prefer to use font-lock-variable-name-face (for parameter declarations) or font-lock-variable-use-face for such identifiers. Though it can be hard to reliably distinguish them in a dynamic language, so as far as I'm concerned, they could stay non-highlighted (the uses, that is; the declarations are usually easy to find using queries).