-
Notifications
You must be signed in to change notification settings - Fork 196
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
Remove keywords from completions #259
Remove keywords from completions #259
Conversation
They were being returned regardless of context which made them very noisy. Related: * elixir-lsp/elixir_sense#99 * #251
@msaraiva one downside to removing this is that now since there is no Do you have any thoughts on how to work around that? Setting cc: @lukaszsamson |
The simplest way I see is to keep adding |
Hmmm, in my testing that probably won't exactly work. When I type "do" I only see a completion request for "d" and not for "do", it seems like VSCode does client side filtering after the initial request. So instead perhaps we could include "do" if the user has typed "d" or "do". |
You're right. I believe VS Code does client-side filtering in this case.
Yeah. We can try that. |
Yes, it does. Currently any further keystrokes only filter the initial list. But I think we can change this with setting
on From the spec
|
That's very interesting. I'm not sure how bad the performance could be impacted by setting Typing Hiting The server uses a strict approach using So I guess we have 3 options, at least:
Performance-wise, |
Man, investigating the auto-complete filtering behavior in LSP was quite the rabbit hole. Here are the two most related issues:
A short summary of those two issues is that we should use
I think 1 isn't really viable since different clients have different behavior, and similarly 3 isn't viable because we can't control that behavior via the protocol. I think I'd like to investigate moving forward with |
Okay, after some testing with |
LSP v3.16 introduces some improvements we can look into
|
They were being returned regardless of context which made them very noisy. Additionally the most important of these ("do/end") is typically inserted by an editor plugin.
Related: