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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Wed, 1 Feb 2023 02:09:02 UTC

Severity: normal

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61205 in the body.
You can then email your comments to 61205 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to casouri <at> gmail.com, dev <at> rjt.dev, bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Wed, 01 Feb 2023 02:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to casouri <at> gmail.com, dev <at> rjt.dev, bug-gnu-emacs <at> gnu.org. (Wed, 01 Feb 2023 02:09:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 'function' in 3rd element of treesit-font-lock-feature-list
Date: Wed, 1 Feb 2023 04:08:38 +0200
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Wed, 01 Feb 2023 05:26:01 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, randy taylor <dev <at> rjt.dev>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Tue, 31 Jan 2023 21:18:36 -0800

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

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 02:35:02 GMT) Full text and rfc822 format available.

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

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, yuan fu <casouri <at> gmail.com>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 02 Feb 2023 02:34:26 +0000
On Tuesday, January 31st, 2023 at 21:08, 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.

If that's what folks decided on then we should keep everything consistent.

Personally, I find it odd that out of the box default highlighting wouldn't highlight function calls.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 02:35:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 61205 <at> debbugs.gnu.org, randy taylor <dev <at> rjt.dev>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 04:34:44 +0200
[Message part 1 (text/plain, inline)]
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.
[ts-modes-refine-features.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 02:45:02 GMT) Full text and rfc822 format available.

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

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: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 04:44:28 +0200
On 02/02/2023 04:34, Randy Taylor wrote:
> On Tuesday, January 31st, 2023 at 21:08, Dmitry Gutov<dgutov <at> yandex.ru>  wrote:
>> X-Debbugs-Cc: Yuan Fucasouri <at> gmail.com, Randy Taylordev <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.
> If that's what folks decided on then we should keep everything consistent.
> 
> Personally, I find it odd that out of the box default highlighting wouldn't highlight function calls.

I think that's more useful in some languages, and less in others.

I guess we settled on this particular convention to be more consistent 
with existing major modes in Emacs. But I can see how it can be 
appealing, especially in languages with more complex syntax such as Rust.

Same for 'property'.

The one feature that I'm fairly certain is currently useless is 
'variable', because we don't have any variable scope tracking (yet), and 
the grammars don't do it for us. So too many tokens get highlighted with 
font-lock-variable-name-face. Try the current rust-ts-mode, for example: 
almost everything ends up with that face.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 03:19:01 GMT) Full text and rfc822 format available.

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

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 02 Feb 2023 03:18:07 +0000
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.

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

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 03:30:02 GMT) Full text and rfc822 format available.

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

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, yuan fu <casouri <at> gmail.com>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 02 Feb 2023 03:29:26 +0000
On Wednesday, February 1st, 2023 at 21:44, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 02/02/2023 04:34, Randy Taylor wrote:
> 
> > On Tuesday, January 31st, 2023 at 21:08, Dmitry Gutovdgutov <at> yandex.ru wrote:
> > 
> > > X-Debbugs-Cc: Yuan Fucasouri <at> gmail.com, Randy Taylordev <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.
> > > If that's what folks decided on then we should keep everything consistent.
> > 
> > Personally, I find it odd that out of the box default highlighting wouldn't highlight function calls.
> 
> 
> I think that's more useful in some languages, and less in others.

Sure, and people will have different opinions on it too. But I still think out of the box we should be highlighting most things like other editors do. It's easy enough to take out what you don't like.

> 
> I guess we settled on this particular convention to be more consistent
> with existing major modes in Emacs. But I can see how it can be
> appealing, especially in languages with more complex syntax such as Rust.
> 
> Same for 'property'.
> 
> The one feature that I'm fairly certain is currently useless is
> 'variable', because we don't have any variable scope tracking (yet), and
> the grammars don't do it for us. So too many tokens get highlighted with
> font-lock-variable-name-face. Try the current rust-ts-mode, for example:
> almost everything ends up with that face.

If anything that isn't a variable is getting highlighted, then that's a bug. Anything it's catching that isn't a variable can probably be dealt with similar to how token_tree is dealt with.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 11:04:01 GMT) Full text and rfc822 format available.

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

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: Re: 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 ;-)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 11:12:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 13:11:30 +0200
On 02/02/2023 05:29, Randy Taylor wrote:
> On Wednesday, February 1st, 2023 at 21:44, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> On 02/02/2023 04:34, Randy Taylor wrote:
>>
>>> On Tuesday, January 31st, 2023 at 21:08, Dmitry Gutovdgutov <at> yandex.ru wrote:
>>>
>>>> X-Debbugs-Cc: Yuan Fucasouri <at> gmail.com, Randy Taylordev <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.
>>>> If that's what folks decided on then we should keep everything consistent.
>>>
>>> Personally, I find it odd that out of the box default highlighting wouldn't highlight function calls.
>>
>>
>> I think that's more useful in some languages, and less in others.
> 
> Sure, and people will have different opinions on it too. But I still think out of the box we should be highlighting most things like other editors do.

Perhaps we should have an extra level between 3 (highlight sparingly 
like other Emacs modes do) and 4 (highlight everything including stuff 
that doesn't always look great).

> It's easy enough to take out what you don't like.

Note that in this case "taking out" some things uncovered that the 
highlighting really isn't great in a different configuration.

>> I guess we settled on this particular convention to be more consistent
>> with existing major modes in Emacs. But I can see how it can be
>> appealing, especially in languages with more complex syntax such as Rust.
>>
>> Same for 'property'.
>>
>> The one feature that I'm fairly certain is currently useless is
>> 'variable', because we don't have any variable scope tracking (yet), and
>> the grammars don't do it for us. So too many tokens get highlighted with
>> font-lock-variable-name-face. Try the current rust-ts-mode, for example:
>> almost everything ends up with that face.
> 
> If anything that isn't a variable is getting highlighted, then that's a bug. Anything it's catching that isn't a variable can probably be dealt with similar to how token_tree is dealt with.

With a list of exceptions? I hadn't thought about that. But it sounds 
like it might be a fair amount of work. Depends on the specific grammar, 
of course.

Note that you'd also need to add such rules for every "feature" that 
might be disabled by the user, for its identifier tokens not to start 
being highlighted as a variable (if the user kept 'variable' in the 
features list). That's the current design we're working off.

And tree-sitter has a recommended mechanism for highlighting locals. We 
just haven't implemented it yet.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Thu, 02 Feb 2023 20:26:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 61205 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>,
 randy taylor <dev <at> rjt.dev>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 22:25:47 +0200
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.

On a related note: 'property' is in level 3 in c-ts-mode.

Should it to go level 4?

Also in typescript-ts-mode.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 02:39:02 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 randy taylor <dev <at> rjt.dev>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Thu, 2 Feb 2023 18:38:37 -0800

> On Feb 2, 2023, at 12:25 PM, 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.
> 
> On a related note: 'property' is in level 3 in c-ts-mode.
> 
> Should it to go level 4?

I believe property is level 3. Quoting the (emacs) manual:

Level 1
     This level usually fontifies only comments and function names in
     function definitions.
Level 2
     This level adds fontification of keywords, strings, and data types.
Level 3
     This is the default level; it adds fontification of assignments,
     numbers, properties, etc.
Level 4
     This level adds everything else that can be fontified: operators,
     delimiters, brackets, other punctuation, function names in function
     calls, variables, etc.

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 02:52:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 61205 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 randy taylor <dev <at> rjt.dev>
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 3 Feb 2023 04:51:04 +0200
On 03/02/2023 04:38, Yuan Fu wrote:
> 
> 
>> On Feb 2, 2023, at 12:25 PM, 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.
>>
>> On a related note: 'property' is in level 3 in c-ts-mode.
>>
>> Should it to go level 4?
> 
> I believe property is level 3. Quoting the (emacs) manual:
> 
> Level 1
>       This level usually fontifies only comments and function names in
>       function definitions.
> Level 2
>       This level adds fontification of keywords, strings, and data types.
> Level 3
>       This is the default level; it adds fontification of assignments,
>       numbers, properties, etc.
> Level 4
>       This level adds everything else that can be fontified: operators,
>       delimiters, brackets, other punctuation, function names in function
>       calls, variables, etc.

The manual could be updated.

Here's where we seem to have agreed that is should be level 4: 
https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01221.html

Even that discussion aside, property accesses and function calls seem to 
be similar enough as syntactic elements (in terms of position, usage, 
and frequency), so they should probably be on the same level. Don't you 
think?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 06:46:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no,
 jostein <at> secure.kjonigsen.net, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 03 Feb 2023 08:45:15 +0200
> Cc: 61205 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>,
>  Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
>  randy taylor <dev <at> rjt.dev>
> Date: Fri, 3 Feb 2023 04:51:04 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> On a related note: 'property' is in level 3 in c-ts-mode.
> >>
> >> Should it to go level 4?
> > 
> > I believe property is level 3. Quoting the (emacs) manual:
> > 
> > Level 1
> >       This level usually fontifies only comments and function names in
> >       function definitions.
> > Level 2
> >       This level adds fontification of keywords, strings, and data types.
> > Level 3
> >       This is the default level; it adds fontification of assignments,
> >       numbers, properties, etc.
> > Level 4
> >       This level adds everything else that can be fontified: operators,
> >       delimiters, brackets, other punctuation, function names in function
> >       calls, variables, etc.
> 
> The manual could be updated.
> 
> Here's where we seem to have agreed that is should be level 4: 
> https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01221.html

Whatever you decide, please keep the doc string of
treesit-font-lock-level and the manual in sync.  I already needed to
fix those more than once because the code "disagreed" with the
documentation.  The pretest is too close for us to be able to sustain
such inaccuracies and resolve them in time.

So please present the patches to this effect for review and comments
before installing them.  TIA.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 06:47:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 03 Feb 2023 08:46:42 +0200
> Cc: 61205 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>,
>  randy taylor <dev <at> rjt.dev>
> Date: Thu, 2 Feb 2023 22:25:47 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On a related note: 'property' is in level 3 in c-ts-mode.
> 
> Should it to go level 4?
> 
> Also in typescript-ts-mode.

What is 'property' in those modes?  In c-ts-mode, is 'property' the
name of a struct or enum member, as in foo.bar?  Or is it something
else?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 11:44:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 3 Feb 2023 13:42:51 +0200
On 03/02/2023 08:46, Eli Zaretskii wrote:
>> Cc:61205 <at> debbugs.gnu.org, Theodor Thornhill<theo <at> thornhill.no>,
>>   randy taylor<dev <at> rjt.dev>
>> Date: Thu, 2 Feb 2023 22:25:47 +0200
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On a related note: 'property' is in level 3 in c-ts-mode.
>>
>> Should it to go level 4?
>>
>> Also in typescript-ts-mode.
> What is 'property' in those modes?  In c-ts-mode, is 'property' the
> name of a struct or enum member, as in foo.bar?  Or is it something
> else?

It's the 'bar' in 'foo.bar', yes. Specifically in the cases where it's 
being looked up, rather than defined (in a type definition). Examples:

	  it2.lnum_pixel_width = it.lnum_pixel_width;

	  || (it.bidi_p && it.bidi_it.scan_dir == -1

'lnum_pixel_width', 'bidi_p', 'bidi_it' and 'scan_dir' are highlighted 
with font-lock-property-face. You can see it for yourself by trying 
c-ts-mode in any of our files.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 12:20:03 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 03 Feb 2023 14:19:40 +0200
> Date: Fri, 3 Feb 2023 13:42:51 +0200
> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 03/02/2023 08:46, Eli Zaretskii wrote:
> >> Cc:61205 <at> debbugs.gnu.org, Theodor Thornhill<theo <at> thornhill.no>,
> >>   randy taylor<dev <at> rjt.dev>
> >> Date: Thu, 2 Feb 2023 22:25:47 +0200
> >> From: Dmitry Gutov<dgutov <at> yandex.ru>
> >>
> >> On a related note: 'property' is in level 3 in c-ts-mode.
> >>
> >> Should it to go level 4?
> >>
> >> Also in typescript-ts-mode.
> > What is 'property' in those modes?  In c-ts-mode, is 'property' the
> > name of a struct or enum member, as in foo.bar?  Or is it something
> > else?
> 
> It's the 'bar' in 'foo.bar', yes. Specifically in the cases where it's 
> being looked up, rather than defined (in a type definition). Examples:
> 
> 	  it2.lnum_pixel_width = it.lnum_pixel_width;
> 
> 	  || (it.bidi_p && it.bidi_it.scan_dir == -1
> 
> 'lnum_pixel_width', 'bidi_p', 'bidi_it' and 'scan_dir' are highlighted 
> with font-lock-property-face. You can see it for yourself by trying 
> c-ts-mode in any of our files.

Then as far as I'm concerned, this can go to level 4, but it must be
done consistently across all the *-ts modes.  So if some mode wants
'property' to be highlighted, and wants it badly, we should IMO keep
it in C as well.

In any case, please make this consistent across all the relevant
modes, and don't forget adjusting the documentation of
treesit-font-lock-level accordingly as needed.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 15:16:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 3 Feb 2023 17:15:05 +0200
On 03/02/2023 14:19, Eli Zaretskii wrote:
>> Date: Fri, 3 Feb 2023 13:42:51 +0200
>> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 03/02/2023 08:46, Eli Zaretskii wrote:
>>>> Cc:61205 <at> debbugs.gnu.org, Theodor Thornhill<theo <at> thornhill.no>,
>>>>    randy taylor<dev <at> rjt.dev>
>>>> Date: Thu, 2 Feb 2023 22:25:47 +0200
>>>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>>>
>>>> On a related note: 'property' is in level 3 in c-ts-mode.
>>>>
>>>> Should it to go level 4?
>>>>
>>>> Also in typescript-ts-mode.
>>> What is 'property' in those modes?  In c-ts-mode, is 'property' the
>>> name of a struct or enum member, as in foo.bar?  Or is it something
>>> else?
>>
>> It's the 'bar' in 'foo.bar', yes. Specifically in the cases where it's
>> being looked up, rather than defined (in a type definition). Examples:
>>
>> 	  it2.lnum_pixel_width = it.lnum_pixel_width;
>>
>> 	  || (it.bidi_p && it.bidi_it.scan_dir == -1
>>
>> 'lnum_pixel_width', 'bidi_p', 'bidi_it' and 'scan_dir' are highlighted
>> with font-lock-property-face. You can see it for yourself by trying
>> c-ts-mode in any of our files.
> 
> Then as far as I'm concerned, this can go to level 4, but it must be
> done consistently across all the *-ts modes.  So if some mode wants
> 'property' to be highlighted, and wants it badly, we should IMO keep
> it in C as well.

Consistency is what I'm after here.

c-ts-mode, as well as go-ts-mode, rust-ts-mode and typescript-ts-mode, 
all previously mentioned in this report, currently put it at 3.

The rest put it as 4, or don't use it at all.

Maybe we'll move them to level 3 for the next release; I think to do 
that, we will have to define separate faces first (for function calls 
and maybe variable references, as soon as we manage to find them in a 
smart way), so that the users will be able to make sure definitions are 
distinct from usages.

> In any case, please make this consistent across all the relevant
> modes, and don't forget adjusting the documentation of
> treesit-font-lock-level accordingly as needed.

Okay.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 15:55:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 03 Feb 2023 17:54:34 +0200
> Date: Fri, 3 Feb 2023 17:15:05 +0200
> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > Then as far as I'm concerned, this can go to level 4, but it must be
> > done consistently across all the *-ts modes.  So if some mode wants
> > 'property' to be highlighted, and wants it badly, we should IMO keep
> > it in C as well.
> 
> Consistency is what I'm after here.
> 
> c-ts-mode, as well as go-ts-mode, rust-ts-mode and typescript-ts-mode, 
> all previously mentioned in this report, currently put it at 3.
> 
> The rest put it as 4, or don't use it at all.

The question is: how important is this for go-ts-mode, rust-ts-mode,
and typescript-ts-mode?  I don't know the answer.  If the importance
is not high, then this should be moved to level 4.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Fri, 03 Feb 2023 17:11:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Fri, 3 Feb 2023 19:10:47 +0200
On 03/02/2023 17:54, Eli Zaretskii wrote:
>> Date: Fri, 3 Feb 2023 17:15:05 +0200
>> Cc:61205 <at> debbugs.gnu.org,casouri <at> gmail.com,theo <at> thornhill.no,dev <at> rjt.dev
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>>> Then as far as I'm concerned, this can go to level 4, but it must be
>>> done consistently across all the *-ts modes.  So if some mode wants
>>> 'property' to be highlighted, and wants it badly, we should IMO keep
>>> it in C as well.
>> Consistency is what I'm after here.
>>
>> c-ts-mode, as well as go-ts-mode, rust-ts-mode and typescript-ts-mode,
>> all previously mentioned in this report, currently put it at 3.
>>
>> The rest put it as 4, or don't use it at all.
> The question is: how important is this for go-ts-mode, rust-ts-mode,
> and typescript-ts-mode?  I don't know the answer.  If the importance
> is not high, then this should be moved to level 4.

Right. They don't seem to be particularly more important there than in 
other modes. Or than 'function', for example.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Sat, 04 Feb 2023 03:37:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Sat, 4 Feb 2023 05:36:15 +0200
[Message part 1 (text/plain, inline)]
On 03/02/2023 19:10, Dmitry Gutov wrote:
> On 03/02/2023 17:54, Eli Zaretskii wrote:
>>> Date: Fri, 3 Feb 2023 17:15:05 +0200
>>> Cc:61205 <at> debbugs.gnu.org,casouri <at> gmail.com,theo <at> thornhill.no,dev <at> rjt.dev
>>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>>
>>>> Then as far as I'm concerned, this can go to level 4, but it must be
>>>> done consistently across all the *-ts modes.  So if some mode wants
>>>> 'property' to be highlighted, and wants it badly, we should IMO keep
>>>> it in C as well.
>>> Consistency is what I'm after here.
>>>
>>> c-ts-mode, as well as go-ts-mode, rust-ts-mode and typescript-ts-mode,
>>> all previously mentioned in this report, currently put it at 3.
>>>
>>> The rest put it as 4, or don't use it at all.
>> The question is: how important is this for go-ts-mode, rust-ts-mode,
>> and typescript-ts-mode?  I don't know the answer.  If the importance
>> is not high, then this should be moved to level 4.
> 
> Right. They don't seem to be particularly more important there than in 
> other modes. Or than 'function', for example.

Here's the updated patch in the meantime.

Not sure what to do with 'type' highlighting in rust-ts-mode yet. 
Additional scoping seems like will require a bunch of repetitions. 
Perhaps a :pred instruction to filter out children of a call_expression 
might work better.
[ts-modes-refine-features.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Sat, 04 Feb 2023 06:54:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Sat, 04 Feb 2023 08:53:59 +0200
> Date: Sat, 4 Feb 2023 05:36:15 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
> 
> Here's the updated patch in the meantime.

Thanks, but please also update the doc string of
treesit-font-lock-level.

> Not sure what to do with 'type' highlighting in rust-ts-mode yet. 

What is the problem with that?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Sat, 04 Feb 2023 23:45:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Sun, 5 Feb 2023 01:44:40 +0200
[Message part 1 (text/plain, inline)]
On 04/02/2023 08:53, Eli Zaretskii wrote:
>> Date: Sat, 4 Feb 2023 05:36:15 +0200
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>> Cc:61205 <at> debbugs.gnu.org,casouri <at> gmail.com,theo <at> thornhill.no,dev <at> rjt.dev
>>
>> Here's the updated patch in the meantime.
> Thanks, but please also update the doc string of
> treesit-font-lock-level.

Done.

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

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.

(Github also highlights function calls, though.)

I'm also adding function parameter highlighting to rust and go modes.

See the attached patch. I suggest we install it in emacs-29, but then 
people are free to tweak the rules further.
[ts-modes-refine-features.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#61205; Package emacs. (Sun, 05 Feb 2023 06:06:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Sun, 05 Feb 2023 08:05:42 +0200
> Date: Sun, 5 Feb 2023 01:44:40 +0200
> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 04/02/2023 08:53, Eli Zaretskii wrote:
> >> Date: Sat, 4 Feb 2023 05:36:15 +0200
> >> From: Dmitry Gutov<dgutov <at> yandex.ru>
> >> Cc:61205 <at> debbugs.gnu.org,casouri <at> gmail.com,theo <at> thornhill.no,dev <at> rjt.dev
> >>
> >> 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?

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




Reply sent to Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility. (Sun, 05 Feb 2023 13:53:01 GMT) Full text and rfc822 format available.

Notification sent to Dmitry Gutov <dgutov <at> yandex.ru>:
bug acknowledged by developer. (Sun, 05 Feb 2023 13:53:01 GMT) Full text and rfc822 format available.

Message #76 received at 61205-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dev <at> rjt.dev, casouri <at> gmail.com, 61205-done <at> debbugs.gnu.org,
 theo <at> thornhill.no
Subject: Re: bug#61205: 'function' in 3rd element of
 treesit-font-lock-feature-list
Date: Sun, 5 Feb 2023 15:52:09 +0200
On 05/02/2023 08:05, Eli Zaretskii wrote:
>> Date: Sun, 5 Feb 2023 01:44:40 +0200
>> Cc: 61205 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, dev <at> rjt.dev
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 04/02/2023 08:53, Eli Zaretskii wrote:
>>>> Date: Sat, 4 Feb 2023 05:36:15 +0200
>>>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>>> Cc:61205 <at> debbugs.gnu.org,casouri <at> gmail.com,theo <at> thornhill.no,dev <at> rjt.dev
>>>>
>>>> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 06 Mar 2023 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 23 days ago.

Previous Next


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