This is also not possible with the current extension design. OCaml has had very smart people build technology for resume-after-error compilation (required for doing anything beyond an error) and buffer compilation (required for feedback before save). Unfortunately the ReScript IDE extension cannot leverage this work as far as I know.
The ReScript extension today mostly just pipes compiler output into the editor in a nice way; this is great for getting an IDE extension off the ground quickly but it doesn’t provide any groundwork for advanced features that go beyond what the compiler is designed to do.
The OCaml IDE tools used to work with ReScript, although only in ReasonML/OCaml syntax, but they dropped support for the version of OCaml ReScript is based on last year.
“Go to definition” seems to work in some places but not others. In this example I can go to definition where the module is referenced within the function body but not for the reference in the type definition.
Thank you all for your posts - keep them coming! Here’s a follow up on some of the pain points you’ve described.
Syntax highlighting
To address this in a sustainable way, we are going to experiment with semantic highlighting. Semantic highlighting means doing this: file contents -> parse to ReScript AST -> produce a set of tokens for highlighting from the AST.
While this will mean a larger up front cost for setting up the infra needed etc, we believe this is the best way forward. We’re hoping it’ll make tweaking the highlighting easy and correct, as it’ll be driven by the real parser and actual AST (which of course is 100% accurate), rather than attempting to reproduce parts of the parser via regexp etc.
Also, we’d be very happy if there’s community members who’d be interested in contributing a bit more in depth to this. We’re going to start by setting up the needed infrastructure and so on, but after that there’s likely going to be quite a lot of work in doing the actual highlighting (matching the various AST nodes and producing semantic tokens from them where appropriate). Most of the work is going to be in OCaml (in the analysis bin of the VSCode extension repo). Please reach out if you’re interested in contributing to this!
Feedback without saving
We hear you, and it would be wonderful to have. Unfortunately, this is an area full of complexity and trade offs. There’s still no decision if this is something that’ll be pursued at all, but if it were, it’d likely require potentially invasive changes to the compiler.
A short follow up, thank you all again for posting your pains and thoughts!
TBH I don’t get why 100% accuracy in syntax highlighting matters. IMO good enough accuracy and enough coloring should be fine for all users.
We can achieve good enough accuracy with TM grammars and the maintenance overhead should be much lower than implementing semantic highlighting.
Another question is how good is the performance of semantic highlighting? i think they should be slower than normal TM grammars due rpc calls etc.
Could someone please provide some environment/OS/rescript info to get a clue why types don’t have a colour for some people, me included? It’s really annoying to switch from other languages during the day and have types coloured the same way as members and arguments.
It’s probably caused by your theme… we made a note in the README that lists all supported themes and also has some further links to discuss the technical difficulties:
A general update on syntax highlighting - we’ve made some good progress, and will hopefully be able to invite testers soon. We’re also going to detail what we’ve done, why we’ve done it, trade offs, guiding principles for highlighting going forward etc as soon as we’re ready to.
The results feel encouraging! We look forward to showing you the results and getting your feedback at some point in the not too distant future.
My pet peeve is that code completion based on type t of a module only works when the file has been saved. So chaining with -> doesn’t suggest the right autocomplete suggestions based on the type of the value that is chained while typing. It also doesn’t work after save because intermediate saves are syntax errors. So the only way to have proper autocomplete is to bind to intermediate values.
Providing correct types in this scenario is another form of “feedback without saving”. It’s a really hard problem that more or less requires running a second version of the compiler designed specifically for partial compilation. As you’ve noted, saving to run the compiler is impossible because there is technically a syntax error—but something that can compile is required to know what the type of an intermediate value is.
There are a lot of areas like this that need to be reinvented, it’s why I was so annoyed when the team chose to create a brand new extension instead of figuring out how to maintain compatibility with existing tools
I guess the fix will be in the next release.
