rescript-vscode
rescript-vscode copied to clipboard
rescript-lang
Explore type based autocomplete
So let's avoid getting carried away by parser recovery which needs to be taken into account but is orthogonal.
What's going on is we do find a label, a function, and an expression being assigned to the label which hits the cursor. Only there's no code to mark that event.
What's needed is code to recognise that event, and emit a new completion primitive for expressions in a type context. E.g. CtypedContext.
I think the next step is to
- Recognise when it is the case that we hit an expression assigned to a label and the label does not hit the cursor but the expression does.
- When that happens, print "found typed context" in debug mode. That print should be visible in the test output.
- As a refinement, also print the name of the function and the name of the label.
Back to you @zth
A print just like others in the file. E.g. here is another example of print from the file if debug then Printf.printf "Attribute id:%s:%s label:%s\n" id.txt (Loc.toString id.loc) label;
@cristianoc I think I got it: https://github.com/rescript-lang/rescript-vscode/pull/493/commits/5ed8bb42b6d7c85ad056c6c4b1ad0675a8937d0b
I added a regular labelled argument completion in TypedContextCompletion.res to help distinguish between the various types.
Awaiting the next steps. Meanwhile, I'll continue exploring where this takes me.
Continued my exploration here: https://github.com/rescript-lang/rescript-vscode/pull/497. Separate PR to make things a bit easier to review.
I'd like to go slowly and make a tiny step at a time.
Let's see how far we can push it before checking for =.
It will mean trying several examples.
And if it does not work for all of them, something will be learned from that.
@cristianoc I've removed the '=' special treatment, and added a few more examples. Looks like a typed context is picked up for everything but an empty assignment, which is likely due to parser recovery omitting the assignment if it's empty.
Having type based completion on an empty assignment is critical I'd say. What do you think is the next step? And are there more examples you'd like to see added?
Need to dig into the example that does not work. With the usual checking in and commenting on the debug output.
@cristianoc Ok, think I made some more progress. I stole a trick from the JSX prop completion that helps me identify the empty assignment.
This is not in the commit, but I also verified that it's indeed a %rescript.exprhole that's being inserted in the expression by the parser error recovery. So the parser does recover the error properly and nicely, I was wrong.
This is great progress! I think we can move on to the next phase and produce the desired result for all the existing examples. Without worrying too much about how things are represented or code duplication for now. (We'll do that after tackling at least one more kind of type context).
This is great progress! I think we can move on to the next phase and produce the desired result for all the existing examples. Without worrying too much about how things are represented or code duplication for now. (We'll do that after tackling at least one more kind of type context).
Awesome! So, essentially, the next step is to produce the list of constructors for completion, disregarding exactly how, what code is shared, how it's represented exactly etc. Did I get that right?
@cristianoc very crude version implemented that produces the correct output. I've tried to familiarize myself with the code a bit. Feel like I'm slowly getting there.
@cristianoc did a little bit of refactoring, and got filtering on prefix working. What do you reckon is the next step?
@cristianoc I couldn't help myself, so I did a bit of exploration on completing polyvariants in addition to regular variants in https://github.com/rescript-lang/rescript-vscode/pull/493/commits/ffa06f417329040f43fc05b916d918103c9ed94b
We can just ignore that for now if it interferes with the process we're doing. Or it's easy to revert as well.