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: 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: 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)]

Previous Next

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