I’m going to be helping out a bit with work on the VSCode extension together with @cristianoc. To better align our work and enable creating a small roadmap, we have the following question for all users:
What are the major pain points using the VSCode extension for you? What improvements/changes would bring the most benefit to you?
Please write down a brief and (preferably) actionable explanation of the pains you are experiencing. One pain per post (fine to answer multiple times). Please take the time to explain what you are experiencing, if possible what changes would fix it, and what benefits fixing it would bring to you.
If you agree with pain points written by other users, please like those posts, so we can get a grasp of how many experience the same thing.
If we think in terms of developer experience, we have a nice language and a nice compiler, but it feels weird being greeted by a mostly white.res file. And when you look into how it was in Reason, it kinda feels like a downgrade as well. And this becomes a problem with larger React components. You can see examples below.
A feature that I use constantly is autocompletion of code. For example, typing “@r [Enter]” would autocomplete @react.component, or if I wanted to call a function SomeLib.theFunction I might only need to type “So [Enter] .th [Enter]” and it would autocomplete the module and function name.
However I need to use a different strategy when using keywords that have autocompletion configured. For example, I use switch frequently and I often type “sw [Enter]” which autocompletes the sample switch statement. I then delete the sample, and then type out “switch” in full. Same idea applies to external where I type “ext [Enter]” and it autocompletes with the sample, which I then delete and then type out “external” in full.
A great improvement for me would be if all keywords that have autocompletion snippets could have just the keyword only autocompletion as the default, and have the snippets available as other options.
In the example above it would be helpful if the type hint would also drill down to show the variants of Next.Image.layout. Otherwise I need to manually lookup the type definition and even then using vscode’s “Go to type definition” doesn’t seem to work.
Matheus, my highlighting is much better than that…maybe something going on locally with your customizations? (Could be another issue, but highlighting is definitely better than youre seeing)
Eg: the screen recorder gif is generated by the online recording website https://www.mnggiflab.com/screen-recorder, and compressed by https://www.mnggiflab.com/gif-compress
I’m with @mxthevs, highlighting is my #1. I still have plans to do a custom extension, my team has just been focussed on our TypeScript codebase recently. Work will resume on the ReScript code in a few months.
My #2 would be updating as I type rather than only on save. This isn’t feasible with the current extension design, of course, but it’s still high on my list as both TS and OCaml extensions are able to do it.
Also, there is another pain point that I just remembered: when you have an error, you lose hover information for everything below the error. Though I’ll have to admit that I don’t know how related to the extension this is.
Can second that, when coding you’ll eventually run into some broken code, meaning I’ll lose all my type information, jump to definition, hovering and etc. arguably at the time I need the info the most, some kind of caching would be nice.
Having to save a file to see error messages, using autosave as a workaround to this issue but then still having to manually save to have the code format on save.
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.
I guess the fix will be in the next release.