Subject: bug#61205: closed (Re: bug#61205: 'function' in 3rd element of treesit-font-lock-feature-list)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 05 Feb 2023 13:53:01 +0000

Your bug report

#61205: 'function' in 3rd element of treesit-font-lock-feature-list

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
61205: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61205
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#61205: 'function' in 3rd element of treesit-font-lock-feature-list
From: Dmitry Gutov <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sun, 5 Feb 2023 15:52:09 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On 05/02/2023 08:05, Eli Zaretskii wrote:
>> Date: Sun, 5 Feb 2023 01:44:40 +0200
>> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> On 04/02/2023 08:53, Eli Zaretskii wrote:
>>>> Date: Sat, 4 Feb 2023 05:36:15 +0200
>>>> From: Dmitry Gutov<[email-masked]>
>>>> Cc:[email-masked],[email-masked],[email-masked],[email-masked]
>>>>
>>>> Here's the updated patch in the meantime.
>>> Thanks, but please also update the doc string of
>>> treesit-font-lock-level.
>>
>> Done.
> 
> Thanks, LGTM.
> 
>>>> Not sure what to do with 'type' highlighting in rust-ts-mode yet.
>>> What is the problem with that?
>>
>> The nodes structure of a 'use' instruction has a lot of nesting, and at
>> least a couple of variations, which would lead to a combinatoric
>> increase in the number of queries.
> 
> If this proves to be a problem in practice, maybe we'll need some
> customization specific to Rust.
> 
>> Taking another look at the declarations, though, I wasn't sure I could
>> understand the specific logic for choosing between font-lock-type-face
>> and font-lock-constant-face.
>>
>> It seemed heavily inspired by
>> https://github.com/tree-sitter/tree-sitter-rust/blob/master/queries/highlights.scm,
>> though. So what I did is reverted to those rules (in that area): the
>> path segments that start with an uppercase char get highlighted with
>> font-lock-type-face. The rest don't get highlighted at all. That's how
>> Rust code looks at Github, so a fair number of developers must be okay
>> with it.
> 
> And this solves the potential combinatoric explosion?

Yes, simply because function names don't start with a capital letter by 
convention. So we don't highlight them as types.

>> See the attached patch. I suggest we install it in emacs-29, but then
>> people are free to tweak the rules further.
> 
> Yes, please install.

Thank you, done, and closing.

Subject: 'function' in 3rd element of treesit-font-lock-feature-list
From: Dmitry Gutov <[email-masked]>
To: [email-masked]
Date: Wed, 1 Feb 2023 04:08:38 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

X-Debbugs-Cc: Yuan Fu <[email-masked]>, Randy Taylor <[email-masked]>

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.