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

[Eli Zaretskii]

> Date: Sun, 5 Feb 2023 01:44:40 +0200
> Cc: 61205@debbugs.gnu.org, casouri@gmail.com, theo@thornhill.no, dev@rjt.dev
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 04/02/2023 08:53, Eli Zaretskii wrote:
> >> Date: Sat, 4 Feb 2023 05:36:15 +0200
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Cc:61205@debbugs.gnu.org,casouri@gmail.com,theo@thornhill.no,dev@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.