GNU bug report logs - #61205
'function' in 3rd element of treesit-font-lock-feature-list

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>
Cc: 61205 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: bug#61205: 'function' in 3rd element of treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 13:03:01 +0200

On 02/02/2023 05:18, Randy Taylor wrote:
> On Wednesday, February 1st, 2023 at 21:34, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> On 01/02/2023 07:18, Yuan Fu wrote:
>>
>>>> On Jan 31, 2023, at 6:08 PM, Dmitry Gutov dgutov <at> yandex.ru wrote:
>>>>
>>>> X-Debbugs-Cc: Yuan Fu casouri <at> gmail.com, Randy Taylor dev <at> rjt.dev
>>>>
>>>> Some new built-in modes has 'function' feature highlighting thus enabled by default.
>>>>
>>>> rust-ts-mode, go-ts-mode, cmake-mode
>>>>
>>>> Should we move it to 4 for consistency with the rest?
>>>>
>>>> Previously, we talked about that and concluded that function calls are usually everywhere and are easy to notice without additional highlighting.
>>>
>>> Right, I think they should be level 4.
>>
>>
>> OK, I tried simply changing that, and it turned out none of these modes
>> have a 'definition' feature, so highlightings get stripped from all
>> definitions as well.
>>
>> And in a couple of cases function calls got highlighted either as a
>> type, or as a property. I fixed the latter by deleting one selector, and
>> the latter didn't touch per se.
>>
>> But since the same modes had 'variable' and 'property' features in the
>> 3rd level as well, I moved them to the 4th (that resolved the incorrect
>> highlighting as property mentioned above, but it's probably need to be
>> improved later, in case someone will want to enable 'property' but not
>> 'function' highlighting).
>>
>> And I added the 'definition' features and moved some highlighting rules
>> there. And added some.
>>
>> So the patch looks a bit more complex than expected, see attached.
>>
>> cmake-ts-mode, in the end, I ended up keeping as-is. The 'variable'
>> selector is more functional there than everywhere else (the grammar uses
>> those nodes for template expansion), and if 'function' is removed, the
>> buffer looks almost devoid of highlighting.
>>
>> Also none of these modes have highlighting for function parameters or
>> assignments. That can be improved later.
> 
> I just took a quick look (will have more time tomorrow hopefully), but:
> 
> Why are there 2 separate definition features for both go and rust?
> There should just be one each.

It was an arbitrary choice on my part: the queries highlight different 
things (with different faces), so I put them separately.

I don't mind if we combine them.

>> -     (scoped_identifier name: (identifier) @font-lock-type-face)
> 
> Why was this removed? I think this will lead to some imports not being highlighted at the very least.

It led to code like 'test1' in test::test1(); being highlighted with the 
font-lock-property-face. I didn't have a lot of time to spend on this, 
so just removed the rule.

Some imports indeed are missing highlighting as a result. Perhaps the 
queries need to be scoped to 'use_declaration' nodes?

> And please keep treesit-font-lock-feature-list alphabetized :).

Sure.

And in case you wanted to propose the next revision of this patch, I 
certainly wouldn't mind ;-)

Previous Next

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