Fix: auto-suggesting a symbol other than the valid, currently-typed prefix

[benhutchison]

Is your feature request related to a problem? Please describe.

Quick Metals "bug" report. Concerns the auto-suggest proposals. In the example screenshot, auto-suggest is ON, there is a field on ts called m, I have typed m and yet the editor is prompting for M, another different field.

Net effect is that I have to do extra work just to select the field that's already fully typed out.

Describe the solution you'd like

If there is a field that exact matches the typed prefix, it should always be most preferred suggestion

Describe alternatives you've considered

leave as is

Additional contex

No response

Search terms

autocomplete

[tanishiking]

@benhutchison Thank you for reporting!

Let me clarify the problem, so

• ts has both fields m and M
• When you type m, the completion should show m first, instead of M then m as your screenshot.
• When you type M, the completion should show M then m

Am I right? That sounds fair enough, and this issue is caused because the fuzzy finder in completion (of metals, probably) doesn't consider the cases (m and M) I guess :)

[ckipp01]

One other thing to note, part of this behavior is due to VS Code filtering. We've seen it a lot before where the order that Metals returns something isn't respected in in VS Code whereas it is respected in other clients. For example testing this out in nvim-metals I can't reproduce the issue since when I type a m if there is a member that exactly matches that it appears first and looking at the LSP logs, the completion also has m as the first item. Furthermore doing a small test with something like this:

object Foo:
    val m = "m"
    val M = "M"

@main def foo =
    Foo.@@

When I trigger a completion on Foo with m I don't even get M back as a completion option. I'd be curious in your case @benhutchison, in this exact scenario that you're showing if you create an lsp.trace.json file, and look at the results of the textDocument/completion, do they match the order that you're seeing in your editor?

[benhutchison]

Behavior differs:

• Ctl-space, then type m: 3 options presented as above
• type m, then Ctl-space: single correct option as shown below.

The relevant lsp trace for incorrect case was massive so wont include here. It included all fields on the object, m, M, E and a whole bunch more, so I it was generated before I typed m and then post-filtered down, maybe by vscode?

[tgodzik]

I think the issue here is that completions are later filtered by VS Code and from what I observed after typing m no further request is sent to the Metals server. I don't see any way around it unfortunately.