[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Standardizing tree-sitter fontification features
From: |
Randy Taylor |
Subject: |
Re: Standardizing tree-sitter fontification features |
Date: |
Sat, 26 Nov 2022 03:35:23 +0000 |
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?
Re: Standardizing tree-sitter fontification features, Stefan Monnier, 2022/11/24
Re: Standardizing tree-sitter fontification features, Stephen Leake, 2022/11/26