Re: Standardizing tree-sitter fontification features

[Yuan Fu]

> On Nov 25, 2022, at 7:35 PM, Randy Taylor <dev@rjt.dev> wrote:
> 
> On Friday, November 25th, 2022 at 15:55, Yuan Fu <casouri@gmail.com> wrote:
>> 
>>> On Nov 25, 2022, at 11:03 AM, Randy Taylor dev@rjt.dev wrote:
>>> 
>>> On Friday, November 25th, 2022 at 01:15, Yuan Fu casouri@gmail.com wrote:
>>> 
>>>>> On Nov 24, 2022, at 5:13 PM, Randy Taylor dev@rjt.dev wrote:
>>>> 
>>>>> I wonder if assignment and definition are really worth having (and would 
>>>>> prefer to do without them), since they should be covered by the variable, 
>>>>> function, type and property features.
>>>> 
>>>> They are definitely useful. They are the things we currently highlight, 
>>>> and for a reason. Personally I only want to highlight identifiers in 
>>>> definition and assignment, not every occurrence of them. Since so much of 
>>>> a program consists of variable and function identifiers, highlighting all 
>>>> of them looks almost like highlighting everything. I just want some visual 
>>>> cues on the program structure, not programming in skittles :-)
>>> 
>>> Fair enough. In that case, are we going to end up with duplication in the 
>>> variable and function features? So long as I can program in skittles, I am 
>>> happy :).
>> 
>> 
>> I don’t think duplication would be a problem. You can disable them, or just 
>> left it on: the face would be the same, the difference is only one which 
>> ones to highlight.
>> 
> 
> I meant duplication in writing the queries. Variable and function queries 
> would already cover most or all of what's in assignment and definition.
> 
>> 
>>>>> - (maybe) literal instead of number? That way there is a group for chars 
>>>>> too (and any other literals if there are any?). Or a char feature in 
>>>>> addition to the existing number one. I'm undecided...
>>>> 
>>>> Literal seems to encompass numbers, strings, chars, and constants. So I 
>>>> don’t know how does it fit. We could add char to string feature.
>>> 
>>> Sounds good. I think I've seen char also end up in constant in some of our 
>>> tree-sitter modes. Doesn't matter to me where it goes.
>> 
>> 
>> Hmm, what does neovim and emacs-tree-sitter do? (If you happen to know)
>> 
> 
> I'm not sure how the neovim stuff works, if it's faces they are defining or 
> features or what. But they get pretty granular, so they've got their own 
> thing for character (they even differentiate between conditionals and 
> loops!!!). emacs-tree-sitter isn't consistent.
> 
> I think it makes sense to include it in string though, just so long as it 
> doesn't have the same face. Perhaps the constant face is best for it?

(Sorry I missed this message)

C-mode uses string-face for chars, and I think it’s fine to use string-face for 
chars, too. They already use different syntax (single quotes), so they 
shouldn’t be hard to distinguish even with the same face.

Yuan