From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wilhelm Kirschbaum Newsgroups: gmane.emacs.bugs Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Date: Sat, 18 Nov 2023 09:50:48 +0200 Message-ID: References: <87y1ewgnn7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000087879f060a688381" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33733"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrey Listopadov , 67246@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 18 08:52:25 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 1r4G7t-0008WC-81 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Nov 2023 08:52:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4G7a-0006yj-19; Sat, 18 Nov 2023 02:52:06 -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 1r4G7V-0006xC-Pn for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2023 02:52: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 1r4G7V-0002Pd-Gu for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2023 02:52:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r4G7W-0005Gs-1t for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2023 02:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Wilhelm Kirschbaum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 07:52: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.170029386920199 (code B ref 67246); Sat, 18 Nov 2023 07:52:02 +0000 Original-Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 07:51:09 +0000 Original-Received: from localhost ([127.0.0.1]:47724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4G6f-0005Fj-3Y for submit@debbugs.gnu.org; Sat, 18 Nov 2023 02:51:09 -0500 Original-Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]:53536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4G6c-0005FC-CA for 67246@debbugs.gnu.org; Sat, 18 Nov 2023 02:51:07 -0500 Original-Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4219f89ee21so15788581cf.3 for <67246@debbugs.gnu.org>; Fri, 17 Nov 2023 23:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700293860; x=1700898660; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=; b=Mwx7zjDAVMGyP/trTo5cfcfokUnIOOLQ7c7ZmQWzFuLsOh0pBxZhIhfDKymiR5Q7eG dHbBqqgOT0zfNsgpMOBo+FZvtYaBXvnSqNIMYOY9JLTEiiTs9aZ6JSk5Q/nf7S8lBCYI lky2snEEb4/F/GVAGink5QEu43ZISx2t+HyfIpSdOoU1q8jQX58rh4KtyzSdK0VBuV47 tlOroYMTem9OYe29UzP0PW9U6qPybQxzRFJQZ+zViQlEJFHXe7P+BDZfdbJ33hWj8XLa 1SBDl29NGp7BOhjspQwFPq/qH95vAZ1mdfj0BkVlSLnoEHlKAXKeYcUiMn9p8F4d3Ehc G81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700293860; x=1700898660; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=; b=IBKJft+/ikN4PezAM44btl6ADSXc8oERFDnsStqE0fLuLg88Gm/KHxc/jEs2Sh7miI d4sWRyUV++YRQFIiUndJkmhjDtN+NjJiaWPEi6VL+g57mYMUizlOOXpB7SRojNGiOYFT Rsa3oUx7y0sIRt+PB7TcRw2FC/e34wnNKv7QNumhfnFzjH9hf5+g4yqYf9zx1jR5Zqlz d6gEwXLA+Zzn11GDzC7g9tlWEEo4LBncAf6+FzJzSvvDYk226DJvkHA7M3LdtbC5tRbR sEmPncUuBspAkBAaEYQb1QF799JJafu5FAMt+7wXb/wYx7nvBLTJk6xLNHO4Vw9Jvuwa vo+Q== X-Gm-Message-State: AOJu0YyvV5tkRYHzqayeAanWfSzYYU6EigImlCnpK59P5YrnegwXJKwB 8PnygJtFOSFLWuUnDRQJl2Zd8GkPyQpqM/opTfc= X-Google-Smtp-Source: AGHT+IEd2R4wRsTpI7yDqT78kvBBn8RlSZmic9Q9/YcvsN4jtXSnt7c+88cHxa9bi7s+l62081FVAL8W4O7l0gGea88= X-Received: by 2002:ac8:5dd4:0:b0:41c:e92a:c604 with SMTP id e20-20020ac85dd4000000b0041ce92ac604mr2333715qtx.59.1700293859836; Fri, 17 Nov 2023 23:50:59 -0800 (PST) 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:274529 Archived-At: --00000000000087879f060a688381 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov wro= te: > 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 =3Dfont-lock-keyword-face=3D is used for both keywords= and > > method calls, as well as for parentheses. The > > =3Dfont-lock-function-name-face=3D is used both for function definition= s, > > parameter names, and calls. Some calls use the > > =3Dfont-lock-keyword-face=3D, for example the call to `raise'. The > > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D. > > > > All of that basically makes Elixir code mostly use 2 colors. > > Additionally, it makes impossible selectively disabling highlighting, a= s > > 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 tim= e. > > 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). > Thanks for the detailed explanation. It's unfortunate timing, because I published a rework of the faces on MELPA so long and a few people are trying it out. It is a total rework using the faces a bit better. I can submit the patch later today and start the conversation from there? Wilhelm --00000000000087879f060a688381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Nov 18, 2023 at 3:36=E2= =80=AFAM Dmitry Gutov <dmitry@gutov.= dev> wrote:
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 =3Dfont-lock-keyword-face=3D is used for both keyword= s and
> method calls, as well as for parentheses.=C2=A0 The
> =3Dfont-lock-function-name-face=3D is used both for function definitio= ns,
> parameter names, and calls.=C2=A0 Some calls use the
> =3Dfont-lock-keyword-face=3D, for example the call to `raise'.=C2= =A0 The
> =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D. >
> 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 i= s
> 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 <= br> 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 no= t
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).
=
Thanks for the detailed explanation. It's unfortunate ti= ming, because I published a rework of the faces on MELPA so long and a few = people are trying it out. It is a total rework using the faces a bit better= .=C2=A0 I can submit the patch later today and start the conversation from = there?

Wilhelm
--00000000000087879f060a688381--