mtoohey31/tree-sitter-koka

Highlighting issue when function has a comment

Closed this issue · 13 comments

// Generate True with probability k/n
fun gen-bool(k: int, n: int) : random bool
  rnd-int32(0, n) < k

image

I can't seem to reproduce this on the latest commit (96d070c). Is it possible there's whitespace in the text where the parsing error appears?

I do run on the latest version that was included with helix-editor/helix#10379
There is no invisible whitespace, I can just copy the text from here into a new koka buffer in helix and it reproduces right away for me. It also reproduces on helix master without config

image

Hmm, that's strange... Running helix from master at helix-editor/helix@dbacaad, it looks like this for me:

image

Just double checking: the issue is that the fun keyword's first letter is highlighted incorrectly, right? Is there any chance you haven't run hx --grammar fetch and hx --grammar build since the update?

I did not, is that necessary? The helix docs suggest that is not needed for pre-packaged grammars.

Whether it's necessary very much depends on how you've installed Helix/how you're running it with Cargo. You can try checking hx --health to figure out what runtime directory it's using (which is where the compiled grammars are located). If you want to be certain that you're running the exact same version of Helix (and the grammars) that I'm testing with, you can use the Nix package manager and run nix run github:helix-editor/helix/dbacaaddcaa4a9dd39c73d0102d03ea7c24ca647#.

I don't believe nix runs on windows, which is where I'm running helix.

I build from source using cargo install --path helix-term --locked. According to the docs this will "construct the tree-sitter grammars in the local runtime folder.". And I set HELIX_RUNTIME to the local runtime folder, ~/prj/helix/runtime in my case.

(If I were to -g fetch manually, it would write the grammars in %AppData%, which I don't want, because then I'd have to copy the queries etc also manually to %AppData%)

I found something strange, I noticed the same thing in a nushell script, also with an if statement prepended with a comment:

# Nushell Environment Config File
if 1 == 1 {
}

image

This, and the fact that you cannot reproduce, suggests to me that something else is going on. Though I have no clue what that could be 🤔

Oh yeah, it's a line ending issue. Setting them to lf removes the artifact in both cases. Now the question is, is that a generic helix problem, or do the queries/grammars of both languages happen to have the same incorrect logic. I'm going to update my helix installation to the latest, to see if the issue persists.

Yeah, it seems the issue persists. Can you reproduce the issue too, with CRLF line endings?

Ah, that's it, yes I can!

image

Will see if I can figure out what's going on. I suspect I just forgot to allow for \r somewhere.

Actually it looks like the problem might be on Helix's end, not the grammar's. If you check :tree-sitter-subtree with the whole document highlighted, there don't appear to be any errors in the tree and I think it looks correct... Given that it happens with Nushell too this should probably be reported to the Helix people. I'm going to keep this open until we've confirmed that it's for sure a Helix problem though.

Issue created at the Helix repo

Closing as this appears to be fixed now that helix-editor/helix#6417 has been merged. Thanks for creating that issue.