feat(lsp): Add autocomplete #1900
Conversation
spotandjake
requested review from
marcusroberts,
ospencer and
phated
as code owners
There was a problem hiding this comment.
Some excellent work here @spotandjake and so fantastic to get this into the LSP!
|
I think we need to go ahead and handle the cases for completion a little better—going ahead and looking for the |
|
I made that change and improved the way detection is done. |
compiler/src/language_server/doc.re
Outdated
There was a problem hiding this comment.
Should we name this file document.re? I don't want to get it confused with doc.re in the formatter.
There was a problem hiding this comment.
Im a fan of that change
spotandjake
force-pushed
the
spotandjake-completion
branch
from
b50da63
to
479b596
Compare
spotandjake
force-pushed
the
spotandjake-completion
branch
from
8a6cdca
to
53ef8b5
Compare
| ); | ||
| }; | ||
|
|
||
| let supressed_types = [Builtin_types.path_void, Builtin_types.path_bool]; |
There was a problem hiding this comment.
Why is this not all builtin types?
| let source = | ||
| Str.global_replace(Str.regexp({|\r\n|}), {|\n|}, source_code); |
There was a problem hiding this comment.
Is this necessary? This is extremely expensive.
| let source_chars = | ||
| List.rev( | ||
| String_utils.explode(String_utils.slice(~last=offset, source)), | ||
| ); |
There was a problem hiding this comment.
This is really expensive too. I imagine it's cheaper just to check string prefixes directly.
| root_decl: Types.module_declaration, | ||
| path: list(string), | ||
| ) => { | ||
| // Get The Modules Exports |
There was a problem hiding this comment.
| // Get The Modules Exports | |
| // Get the module's exports |
| Some(build_type_completion(~env, (ident.name, decl))) | ||
| | TSigModule(ident, decl, _) => | ||
| Some(build_module_completion(~env, (ident.name, decl))) | ||
| // Dissabled |
There was a problem hiding this comment.
| // Dissabled | |
| // Disabled |
| // Find The Top Level Modules | ||
| let completions = | ||
| switch (search) { | ||
| // User Wrote Nothing |
There was a problem hiding this comment.
| // User Wrote Nothing | |
| // User wrote nothing |
| switch (search) { | ||
| // User Wrote Nothing | ||
| | [] | ||
| // User Wrote A Single Word, i.e Top Level Search |
There was a problem hiding this comment.
| // User Wrote A Single Word, i.e Top Level Search | |
| // User wrote a single word, i.e top-level search |
| | [] | ||
| // User Wrote A Single Word, i.e Top Level Search | ||
| | [_] => completions | ||
| // User Wrote A Path |
There was a problem hiding this comment.
| // User Wrote A Path | |
| // User wrote a path |
| | [_] => completions | ||
| // User Wrote A Path | ||
| | [search, ...path] => | ||
| // Find Module Root |
There was a problem hiding this comment.
| // Find Module Root | |
| // Find module root |
| } | ||
| }; | ||
| // Remove Operators | ||
| let operators = [ |
There was a problem hiding this comment.
Would also be good to have this at the top level.
|
@ospencer if you get a chance would you be willing to review the new implementation. It needs more work before its good so im going to convert this to a draft. |
…e are writing an identifier.
spotandjake
force-pushed
the
spotandjake-completion
branch
from
807a91b
to
443d057
Compare
This pr adds autocomplete to the grain language. I think we may want to expand this in the future. Possibly with a better parser to improve finding the current context of completion. Right now we just treat
=as indicating you want value completions and:as indicating you want type completions There are a few issues with this approach though, such as ew do not currently trigger completions1 + <here>in the position of<here>and other similar cases. we also mistreattype T =as value completions currently, so some more consideration may need to be given on parsing rules. Im opening the pr now though as I am hoping to get feedback on parsing rules here.Another possible addition would be to try and use the
sourceTreeto give context, I didnt take this approach as in most casessourceTreeis very far behind where your autocompleting and not very helpful, it would have to be used in addition to the half parser though rather than as an alternative.Another possible future expansion is adding autocompletes to
includes that scan the directory for.grfiles and suggest them. I think this could come in a later pr though, maybe after we determine the newincludesyntax.Another possible future expansion would be adding snippet completions to keywords. but i feel this can come in a later pr.
This pr replaces: #1262, Thanks to marcus for the initial implementation from that pr.