tree-sitter-dart about nvim-treesitter HOT 17 CLOSED

👍 I'll try and tinker with it and open a PR, this is already really great for standard dart. Flutter is native rather than nested so won't need anything special I don't think just highlights for classes, methods and operators

from nvim-treesitter.

Most other parsers use

((namespace_identifier) @type
 (#match? @type "^[A-Z]"))

for types. The regexes are evaluated as vim regexes (very magic) so they might behave a bit weird (with escaped \, I've never fully understood vim regexes): https://github.com/neovim/neovim/blob/bd5f0e9695cb21c8b97f844ce21432ee8d06b7ed/runtime/lua/vim/treesitter.lua#L133

This causes some problems: neovim/neovim#12595

from nvim-treesitter.

@UserNobody14 as far as I had a looked the parsed syntax trees right now: the quality of the parsing results are pretty good 👍 . We should be able to find out all missing information by additional queries and analysis of the AST.

from nvim-treesitter.

Could you try out: #215 and tell whether the parser is serving you well?

What is the ftype for dart? Is it 'dart'?

from nvim-treesitter.

Woah this is super exciting thanks for picking this up so quickly. I (overeagerly) just tried it out on a project and it works quite well. It seems to be missing a lot of class related highlights though and dart is pretty heavy on the classes so in a file using a framework like flutter it's almost entirely white

Tree sitter

Random old screen grab of vim syntax (The vscode bit isn't relevant here just an old screen grab)

I think the classes and operators aren't highlighted as well as methods etc. Most of the class related highlighting comes up a lot in dart

from nvim-treesitter.

I've never seen dart in my life, so I just copied some stuff from the upstream repo together. Feel free to improve the highlights by adding new queries. For nested languages, we need language injection support for neovim though.

from nvim-treesitter.

I'm one of the contributors on the tree-sitter-dart repository. Definitely highlighting has not been a focus for us right now. We have been mostly focusing on getting the grammar to work properly for the newest dart syntax, including non-nullable types. There are some corner cases of the language grammar that aren't currently handled still (Very small chance of it appearing in user code). I can work on the highlighting queries a bit later on this week, but if any of you have time and want to work on it feel free to open a pull request.

from nvim-treesitter.

@Akin909
I think some of the difficulty with the classes is that it is hard from a parser to tell what is a class and what is a function (from the callsite). You have to do more than just parsing for that - you have to analyze the code (especially where the new and const keywords aren't used). I'd have to look deeper at the grammar to see if the grammar currently distinguishes between the two in the calling / instantiating position. If so, it would be easy to add highlighting. If not (which is what I expect), it could get much harder. Possibly if we can figure out which ones are uppercased, we could just apply a blanket rule that Uppercased 'function calls' should be highlighted like classes. I'm not super familiar with the highlighting features of tree-sitter, but I can take a look at them later this week probably.

from nvim-treesitter.

I think some of the difficulty with the classes is that it is hard from a parser to tell what is a class and what is a function (from the callsite).

@TimWhiting that makes sense I just tried the treesitter UI in tree-sitter-dart to have a look at the tree that is created and can see what you mean i.e. classes all come up as identifiers. I think uppercased function calls would be a good work around if needed since I think that would cover most cases, except this wouldn't translate to instances (not sure if that's necessary anyway).

I've also noticed that there's no way to distinguish methods and properties which also come up as identifiers. Although as these are prefixed with .thing are maybe easier to identify (I'm guessing, I'm not sure how that would be conveyed with treesitter).

I haven't worked with treesitter before but from what I can see languages like go that use structs and java which has classes seem to be able to determine which nodes are classes or class-like but I guess that might not be applicable here.

Some sort of indicator that certain things are classes would be super helpful since at the moment I don't think there is a way to highlight these. I'm currently just looking at adding operators, punctuation and a few keywords.

EDIT: I just realised that you might have meant adding the upper cased rule as a highlight query? I have no idea how or if that's even possible I was wondering if it would be possible to have that group defined somehow in the grammar?

from nvim-treesitter.

@Akin909 there's already some regex query's for naming conventions in the highlight queries (look for match?). Also, we have plans to make highlighting more semantic in future. You can already ask this plugin for a definition. In future, we want to leverage this information also for highlight (e.g. distinguishing types from values and local from imported names and parameters).

from nvim-treesitter.

Ah I've just seen the example thanks @theHamsta, I actually think the regex in there isn't working very well, locally it seems to only catch one or 2 matches not sure why. I tried

((identifier) @type
(#match? @type "^[A-Z][a-z]+(\?:[A-Z][a-z]+)*$"))

in the tree sitter UI which catches most of the classes in my test file but when I add it to highlights.scm in your PR only partially matches some of the classes (but still a lot more than are in the current regex).

Would be good to know definitively if we can't get a class identifier from the grammar since this seems like it's going to be a bit brittle no matter 😓

from nvim-treesitter.

That works much better 💯

from nvim-treesitter.

Are those underscored names members? You could add a highlight for them as well.

from nvim-treesitter.

They are, I did a quick search and found

((identifier) @field
 (#match? @field "^_"))

Which I've added. I've got a few tweaks locally which I think improve the highlighting, operators keywords etc. Think there's still a bunch that could be added down the line with all of this stuff think it'd be a very good start I can make a PR later. My branch is based on yours in #215

It's only a few lines tbh so could just share a patch which you can apply if you want?

EDIT: I removed the query above since it matched too aggressively since you can have classes such as _StateClass which I wouldn't have wanted to have the class highlight overridden. Not sure if it's possible to constrain this to the body of a class maybe

((class_body) (identifier)...) // I don't know how the syntax would work

from nvim-treesitter.

((identifier) @type
 (match? @type "^_?[A-Z]"))

((identifier) @field
 (match? @type "^_[a-z]"))

; or 
(class_body
         (identifier) @field)
; or
((class_body
         (identifier) @field)
 (match? @field "^_[a-z]"))

It works like Lisp just enclose the query to the parens of the parent

from nvim-treesitter.

Hey, I'm the guy who first started the dart tree-sitter implementation.

To answer your question about why so many things are just 'identifier', it's just because that's how it's laid out currently in the queries/highlights.scm file. The definitions exist, and cover almost everything in the dart specification, but the highlight file may not have complete coverage.

I'm not very knowledgable about the common practices of writing a grammar for syntax highlighting, unfortunately. I'd be happy to help in any way I can though, as Tim said, just open a pull request or an issue.

If you're interested in how our grammar handles various situations, you can look in the 'test' folder of our repository, which has a lot of different dart code examples, alongside their grammatical output.

from nvim-treesitter.

@UserNobody14 thanks for the heads up 👍 , I had a very quick look through the grammar and it looks like a few things like method_invocation and method_reference are commented out at the moment as is class_literal (which I'm guessing would cover the cases we are currently using a regex for), field_access etc (one example line).

Other than that as you say there's quite a lot already defined. I'll have a look at the output for some of the tests. I can raise an issue on the grammar repo to discuss this more over there if you'd prefer. It could be there's already ways around these things that I'm just unfamiliar with.

from nvim-treesitter.