LSP Completions from ruby LSP are not displayed when typing a string literal in VSCode

[taylorthurlow]

Summary

Completion suggestions for Ruby are triggering at unexpected times/locations when using string literals as method arguments.

Steps to trigger the problem:

1. Set up Ruby LSP:

   {
     "languages": {
       "Ruby": {
         "language_servers": ["ruby-lsp", "!solargraph", "!rubocop", "..."]
       }
     }
   }

2. gem install ruby-lsp (requires Ruby to be installed, I used Ruby 3.3)

3. Open a new Ruby file and reproduce issue in similar fashion to recorded video below.

Actual Behavior:

Screen.Recording.2025-01-30.at.10.36.52.AM.mov

Additionally, adding parentheses to the method call (e.g. it("string literal")) does not have any effect.

Expected Behavior:

The expected behavior is visible in the VSCode window in the above video. When the string literal is typed I should not be seeing completions for the text that occurs before the string I am typing.

[vitallium]

I think I reproduced that behavior. When I typed it "string argument dsf.|" (| this is my cursor) in VSCode, I saw that Ruby LSP returned me completions even my cursor is inside the string currently:

2025-01-31 17:39:29.674 [info] (festivatica) [Trace - 17:39:29] Sending request 'textDocument/completion - (198)'.
2025-01-31 17:39:29.674 [info] (festivatica) Params: {
    "textDocument": {
        "uri": "file:///Users/vslobodin/Development/festivatica/app/models/category.rb"
    },
    "position": {
        "line": 8,
        "character": 24
    },
    "context": {
        "triggerKind": 1
    }
}
2025-01-31 17:39:29.676 [info] (festivatica) [Trace - 17:39:29] Received response 'textDocument/completion - (198)' in 2ms.
2025-01-31 17:39:29.676 [info] (festivatica) Result: [
    {
        "label": "itself",
        "labelDetails": {
            "detail": "()",
            "description": "kernel.rbs"
        },
        "kind": 2,
        "filterText": "itself",
        "textEdit": {
            "range": {
                "start": {
                    "line": 8,
                    "character": 0
                },
                "end": {
                    "line": 8,
                    "character": 2
                }
            },
            "newText": "itself"
        },
        "data": {
            "owner_name": "Kernel",
            "guessed_type": false
        }
    }
]

Probably VSCode does additional filtering or something?

Here is the Ruby LSP log for the same scenario:

// Send
{
  "jsonrpc": "2.0",
  "id": 139,
  "method": "textDocument/completion",
  "params": {
    "textDocument": {
      "uri": "file:///Users/vslobodin/Development/festivatica/app/models/category.rb"
    },
    "position": {
      "line": 7,
      "character": 24
    },
    "context": {
      "triggerKind": 1
    }
  }
}

// Receive
{
  "id": 139,
  "result": [
    {
      "label": "itself",
      "labelDetails": {
        "detail": "()",
        "description": "kernel.rbs"
      },
      "kind": 2,
      "filterText": "itself",
      "textEdit": {
        "range": {
          "start": {
            "line": 7,
            "character": 0
          },
          "end": {
            "line": 7,
            "character": 2
          }
        },
        "newText": "itself"
      },
      "data": {
        "owner_name": "Kernel",
        "guessed_type": false
      }
    }
  ],
  "jsonrpc": "2.0"
}

[probably-neb]

Phew yeah that looks like it's annoying.

Probably worth looking into how best to support hiding completions in a language specific way (probably through extensions) so we can provide a good UX even with chatty LSPs.

I'm going to move this to discussions so we can keep tracking this as it's a desired feature from VSCode rather than a bug in Zed.

[taylorthurlow]

Thanks for looking at the issue. Just want to confirm that you do think this is technically a problem with the language server sending completions when it probably otherwise shouldn't? The completions available are always useless, as they effectively completely ignore the presence of the string being typed, including the opening (or closing) quotation mark.

Presumably VSCode wouldn't have implemented the feature unless it was a common issue, but I don't understand enough about how LSP works, and how this ends up working in practice.