GNU bug report logs - #67246
30.0.50; elixir-ts-mode uses faces inconsistently

Previous Next

Full log

Message #8 received at 67246 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org,
 Wilhelm H Kirschbaum <wkirschbaum <at> gmail.com>
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 18 Nov 2023 03:36:26 +0200

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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.