-
Notifications
You must be signed in to change notification settings - Fork 56
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
Autocomplete for custom Option module instead of Belt.Option #909
Comments
The same goes for arrays and other built-in modules |
This would be a good configuration option and I'm really not against the idea (would enhance the DX for sure), but the problem is where we should have the user put this type of custom configuration. |
Is a config even necessary? (Note, that I'm not aware of the actual algorithm used: Would autocomplete suggest other Modules after Belt? How about for rescript 11? Would it suggest Core?) Could just heuristics be used? Like calculate a "distance" of a possible suggestion to the current file and order suggestions according to shortest distance. Similar to:
|
The current heuristics are very simple and rely on just checking whether Core is opened or not, then decides on what module to complete from for each builtin type. This is very simple which also means it's really fast. No need to read any actual type information from files that you won't end up using. And that's the problem with an approach like above - you'd end up reading type information (which is expensive) for many many files. And some general issues around how to decide what module to pick, and so on. |
We have a vendored stdlib which exposes the
Option
module, and it would be nice to get autocomplete for it instead ofBelt.Option
.The text was updated successfully, but these errors were encountered: