Repository navigation
Autocomplete frequently does not work #2873
Description
Description
Ruby LSP Information
VS Code Version
1.95.3
Ruby LSP Extension Version
0.8.13
Ruby LSP Server Version
0.21.3
Ruby LSP Addons
- Ruby LSP Rails
Ruby Version
3.3.4
Ruby Version Manager
rbenv
Installed Extensions
Click to expand
- auto-add-brackets (0.12.2)
- endwise (1.5.1)
- gitlens (16.0.0)
- rails-snippets (1.0.8)
- rainbow-csv (3.12.0)
- ruby-lsp (0.8.13)
- spaces-inside-braces (0.4.0)
Ruby LSP Settings
Click to expand
Workspace
{}User
{
"enableExperimentalFeatures": false,
"enabledFeatures": {
"codeActions": true,
"diagnostics": true,
"documentHighlights": true,
"documentLink": true,
"documentSymbols": true,
"foldingRanges": true,
"formatting": true,
"hover": true,
"inlayHint": true,
"onTypeFormatting": true,
"selectionRanges": true,
"semanticHighlighting": true,
"completion": true,
"codeLens": true,
"definition": true,
"workspaceSymbol": true,
"signatureHelp": true,
"typeHierarchy": true,
"references": true
},
"featuresConfiguration": {},
"addonSettings": {},
"rubyVersionManager": {
"identifier": "auto"
},
"customRubyCommand": "",
"formatter": "auto",
"linters": null,
"bundleGemfile": "",
"testTimeout": 30,
"branch": "",
"pullDiagnosticsOn": "both",
"useBundlerCompose": false,
"bypassTypechecker": false,
"rubyExecutablePath": "",
"indexing": {},
"erbSupport": true,
"useLauncher": false,
"featureFlags": {}
}Reproduction steps
I very frequently have autocomplete not populating my autocomplete options with all the options it should. I'm exclusively talking about autocompleting actual things that are already in my code, not things from the Ruby language. For example, it's very common for me to define a variable or a method and then literally on the very next line, when trying to call it, not have the name as an autocomplete option. I do a lot of extra copying/pasting to make up for this annoying behavior. I'd like to provide more helpful info but it behaves erratically. Sometimes it works, sometimes it doesn't.
I also notice (in case it's related) that there are some files which will not fuzzy search properly when I'm doing Command+P and opening an existing file. With most files, I can type part of the name or add some typos and it still comes up with it in the results but with some, it will not appear unless I type most of it very carefully. Again, not sure if that's a related issue but I'm including it just in case it is.
As a former user of Atom and Sublime Text, I've never seen so many issues with a basic feature (autocomplete) before. I've been experiencing this for years and keep hoping others will notice it and it will be fixed in an update, but the behavior persists so I'm creating an issue. I previously used the autocomplete features that come out of the box with VS Code and solargraph, before moving to Ruby LSP because it seemed to be the most popular. My primary motivation for making those changes has been to try to address these issues. I have simple needs. I've found it quite difficult to find anyone else online that's reporting this same kind of buggy behavior, but I can't be the only one!
Code snippet or error message
None.
Activity
vinistock commentedon Nov 18, 2024
Thank you for the report. Let me first address this point:
Language servers (or even extensions) cannot influence VS Code's file search, so this is not related to the Ruby LSP. It might be that certain files are being excluded from search with the
search.excludesetting or that an extension is contributing extra exclusions. The Ruby LSP itself only excludes its own.ruby-lspdirectory from search and nothing else.Regarding everything else you mentioned, what you're experiencing is the lack of a type checker and a type system. Analyzing the type flow of your program to understand what are the possible types so that accurate completion can be provided.
Projects such as Sorbet can do exactly what you're talking about, provided you onboard to their type system. Play around with this example, for instance. You get accurate completion for instance variables because the type checker is analyzing the code.
Unlike Sorbet, the Ruby LSP itself doesn't require Ruby projects to onboard to a type system, which limits the accuracy of the analysis we can perform. We discuss this in our roadmap and design document.
We also explored if it would be beneficial to try to perform type flow analysis even in projects that are not onboarded to a type system. That means, essentially building an entire type checker without a type system to go along with it.
We wanted to understand how far we would be able to go in terms of accuracy if we could analyze types despite the lack of annotations. What we found is that the percentage of cases where you would be able to reliably detect the right type was too low to justify the enormous effort of building a type checker from scratch.
I should also mention that, even with a type system, there are still cases where completion will be unavailable because certain Ruby features are too difficult (or impossible) to analyze statically (think meta-programming things such as
sendormethod_missing).Performance is also a critical requirement. If language servers take too long to respond (and for them anything over 200-500ms is already pushing it), you start experiencing lag and lack of responsiveness in the editor. So often there's a tension between correctness and performance. It might be possible to analyze certain pieces of code and accurately determine the associated types, but if that massively degrades performance then it may not be worth doing.
I will convert this to a discussion, so that folks can continue the conversation and hopefully even find novel ideas in this space.