Autocomplete frequently does not work

[em77]

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.

[vinistock]

Thank you for the report. Let me first address this point:

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

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.exclude setting or that an extension is contributing extra exclusions. The Ruby LSP itself only excludes its own .ruby-lsp directory from search and nothing else.

I've been experiencing this for years

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 send or method_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.

[em77]

@vinistock You're telling me that I can't expect consistent results with autocomplete results when it comes to variables (or anything) I've already typed in a file (or across files), without the project I'm working on using sorbet?

[vinistock]

It depends on the case. If the type is unambiguous and can be determined without any type annotations, then we can provide correct completion results, but the effort to do so is hard to justify. For instance take this example:

deffoob="hello"a=bifsomethinga=123enda.# << completion trigger hereend

To provide correct completion on this very simple example, you still need to

1. Implement keeping track of lexical scopes. You need to know when variable enter and leave contexts, so that's a requirement
2. Implement reaching definitions to be able to detect that a is initialized to the same type as b within the same scope
3. Implement at least the fundamentals of a type system internally. Even if you don't have any annotations involved, the type of a is a type union of String | Integer. To provide accurate completion, you need to implement the concept of a type union internally. That means you need a considerable amount of the fundamental infrastructure for a type system to analyze even cases that are simple like this

What I mentioned about our exploration is that we collected data about how many cases could we detect the correct type if we invested the effort to implement all of this. And what we discovered based on a few application samples is that we wouldn't be able to accurately discover a decent percentage of types without any annotations.

Note that this is not a Ruby thing. It's a characteristic of languages that do not have static or gradual typing. If you experiment with JavaScript or Python (without using type hints), you will see that in many cases you will also not have completions available. Getting more accurate static analysis on programs and better tooling is precisely the reason why TypeScript was created and why Python added support for type hints.

In Ruby, the collection of possible cases that you can accurately detect the type without annotations is even smaller than in JavaScript and Python, simply because Ruby is significantly more dynamic than them - which exacerbates the issue.

In addition to Ruby's rich dynamic nature, Ruby doesn't have a packaging system (like Python and TypeScript do). This also has consequences for static analysis. Everything in Ruby ends up in the global namespace, which means that analyzing code statically requires analyzing the entire codebase, since the type checker doesn't have a dependency tree to minimize the amount of code it needs to analyze. To try to clarify this with an example, if you change the parent class in a file, it's not possible to know ahead of time which other files may be impacted by that change because of the lack of packaging. You need to re-check the entire codebase for errors. This characteristic puts an even more intense performance constraint on type checkers for Ruby because the analysis can't happen in a subset of the codebase.

You're telling me that I can't expect consistent results with autocomplete results when it comes to variables (or anything) I've already typed in a file (or across files), without the project I'm working on using sorbet?

That's essentially correct. Completion is one of the features that depends on accurate type checking the most, but to fully type check code you need type annotations to guide the type checker.

It does not need to be Sorbet necessarily, Steep and Typeprof are other gradual typing solutions for Ruby available.

[robmck1995]

Does this mean that if a project already uses a typing solution, the performance of Ruby LSP will be better?

[vinistock]

That is our desired vision: to have the Ruby LSP work even without type annotations and then become smarter if you decide to adopt a type system.

Currently, we're not there yet. It will detect if your project uses Sorbet and then refrain from providing certain features depending on the type sigil on each file. For example, Sorbet can provide constant completion even on typed: false, so in that case we don't provide constant completion if Sorbet is present.

[iain]

What about keyword arguments? Is that also impossible without static typing, or am I misconfiguring something?

For example:

(seeing no errors in Output)

[vinistock]

That specific example is just a missing feature in our completion implementation. We can definitely provide completion for the keyword arguments when we can determine which method you are referring to.

I created an issue to track the work #2913.

[em77]

So I’m not familiar with solving these kinds of problems, but given that other editors never seem to have the basic issues I described, completing variable names, my assumption is that there’s a much cruder autocomplete system. Like why can’t the editor just index all the text and autocomplete from that? When I define a variable and then on the very next line I’m not getting autocomplete results that include that variable, it just feels wrong and I never experienced this on Sublime or Atom. And again, this only happens sometimes, but frequently enough that it’s annoying. So it’s not like it never works like this. It works most of the time. But I experience this issue probably at least once every day.

…

On Tue, Nov 26, 2024 at 10:40 AM Vinicius Stock ***@***.***> wrote: That specific example is just a missing feature in our completion implementation. We can definitely provide completion for the keyword arguments when we can determine which method you are referring to. — Reply to this email directly, view it on GitHub <#2876 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3ZBXRD4A7N4TWGFACZYFL2CSI6NAVCNFSM6AAAAABSGXUYIWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZYGUZDKMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vinistock]

What you're describing, which is showing completion suggestions based exclusively on text and not static analysis, is supported by VS Code. You can control that with the "editor.suggest.showWords" setting, which will include existing words in the opened documents as part of completion suggestions. Maybe you have that turned off?

Also, we do have completion for local variables, but maybe you encountered a bug that happens in a specific scenario? It's hard to tell without an exact example of which code triggers the lack of completion.

[em77]

@vinistock I have the showWords setting enabled.

[lucasbalena]

ruby.mp4

Am I doing something wrong?
@vinistock

[vinistock]

This is the same case I explained here and potentially in some other issues.

To perform complete type flow analysis and understand what types are propagating through the program, the Ruby LSP would need to implement a proper type system. You need to keep track of the types of each variable, in which lexical scope they exist and you need to implement at least type unions under the hood to express things like nilability.

We did an exploration to understand how accurate the Ruby LSP could become if we implemented all of that without requiring type annotations from users. Unfortunately, our findings were that the increase in correctness was very small - especially when compared to the amount of effort to implement all of this.

Based on that, the Ruby LSP does not implement a full type checker or type system. If you require more accuracy and correctness, you may want to consider adopting Sorbet or Steep.