Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update tree-sitter-julia #10031

Conversation

Iorvethe
Copy link
Contributor

@Iorvethe Iorvethe commented Mar 28, 2024

This PR updates the parser to the latest version, and adapts the queries accordingly. Some changes were also brought from nvim-treesitter’s queries as well.

In light of the reversing of the queries (#9458), the order has also been changed. It tried to mimick the sections of the previous queries, while also following those of nvim-treesitter to ease future updates (the diff will be more useful).

Everything seems to be working. There is just a tiny issue with indentation after compound blocks or for-loops. Specifically, the outdent after them should not happen. For example, the cursor on the line ends up here:

function f()
    for i in 1:10
    end
|
end

While it should end up like so:

function f()
    for i in 1:10
    end
    |
end

This worked before (on 23.10, but not on master), and the indent queries remain more or less the same, so I don’t see what should be changed. From my tests, it seems recurring in other languages like fish that finish indent scopes with a keyword that is not indented. Any help is welcome!

I found out about the indentation heuristic, and the peculiar indent seems to be from it. So, not an issue with the PR. It would still be better if we could have the hybrid indentation (the default) while avoiding the outdent after the end.

Also, it would be nice if those who worked on the queries previously could take a look to see whether everything is working and whether they are fine with the new structure.

Closes #7309

Update julia parser to latest version, along with:
- updating the queries,
- pulling changes from `nvim-treesitter`’s queries (as the maintainters
  of the parser update the queries there),
- reversing the queries’ order to be compatible with upstream.
@the-mikedavis the-mikedavis added S-waiting-on-review Status: Awaiting review from a maintainer. A-language-support Area: Support for programming/text languages labels Mar 29, 2024
@the-mikedavis the-mikedavis self-requested a review March 29, 2024 13:33
@VarLad
Copy link
Contributor

VarLad commented Apr 28, 2024

(sorry for the noise)
Thanks a lot for the PR!
For any RedHat/Fedora user here, I'm building this at https://copr.fedorainfracloud.org/coprs/varlad/helix until (if) this PR is merged and released.

I also didn't get an issue with this which I had with the previous queries, that is the entire file lost color while editing randomly (:config-reload fixed it every time).

@Iorvethe
Copy link
Contributor Author

Happy that you like it and thank you testing it! I think it will a bit of time before it gets merged, since the ordering of the queries MR (on which this one depends) has to be merged first, but hopefully before the next majour release!

@archseer archseer merged commit 17bb6b4 into helix-editor:reverse-query-precedence-ordering May 17, 2024
6 checks passed
archseer pushed a commit that referenced this pull request May 17, 2024
Update julia parser to latest version, along with:
- updating the queries,
- pulling changes from `nvim-treesitter`’s queries (as the maintainters
  of the parser update the queries there),
- reversing the queries’ order to be compatible with upstream.
@VarLad
Copy link
Contributor

VarLad commented May 19, 2024

@Iorvethe The same COPR now builds against the head of reverse-query-precedence-ordering branch.
Although highlighting is currently entirely broken for Juila now (on that branch) :P

@Iorvethe
Copy link
Contributor Author

Iorvethe commented May 19, 2024

I just tried it and it’s broken indeed… This is very strange as this branch was started from reverse-query-precedence-ordering and so should include the changes there.

The culprits seem to be the first few queries using match? instead of #match?. I will push a PR to fix it, but it’s nonetheless weird that it worked before, but not after being merged.

Update: see #10793

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-language-support Area: Support for programming/text languages S-waiting-on-review Status: Awaiting review from a maintainer.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants