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

[Dmitry Gutov]

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@debbugs.gnu.org,casouri@gmail.com,theo@thornhill.no,dev@rjt.dev
> > > From: Dmitry Gutov<dgutov@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
Description: Text Data