Skip to content
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

Jump to bottom

x/tools/internal/lsp: consider not trimming completion "filterText" prefix #31552

Closed
muirdm opened this issue Apr 18, 2019 · 3 comments
Closed

x/tools/internal/lsp: consider not trimming completion "filterText" prefix #31552

muirdm opened this issue Apr 18, 2019 · 3 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls.
Milestone
Unreleased

Comments

@muirdm
Copy link

muirdm commented Apr 18, 2019 •
edited

Breaking this out from #31178 (comment)

For completions, currently gopls sets filterText to the prefix-trimmed completion candidate. For example when completing at fmt.P<> you will get back a candidate with label of "Print(...)" and a filterText of "rint". This breaks lsp-mode in emacs because "P" does not match the filter text "rint".

I surveyed some other clients/servers regarding filterText:

  • java/rust/python servers don't set filterText
  • clangd sets it, but does not trim the prefix
  • vscode seems to match using the label or filterText, so you can mix and match from either (that is why the trimmed prefixes don't break vscode). the lsp spec seems to suggest filterText should supersede label if present, but maybe vscode does this to be more lenient in general.
  • sourcekit-lsp sets it, but doesn't seem to filter the candidates at all based on the already-typed prefix

I haven't found any hard evidence saying filterText must include the full identifier, but at this point I think gopls should not trim the prefix.
@gopherbot gopherbot added this to the Unreleased milestone Apr 18, 2019
@muirdm muirdm mentioned this issue Apr 20, 2019
Open
@stamblerre stamblerre mentioned this issue Apr 20, 2019
Closed
@stamblerre
Copy link
Contributor

Sorry for not responding to this earlier. The reason I set the filterText is specifically because of the behavior of VSCode. The example I found was this:

I have 2 variables in scope item and insertText. Without filter text, I type i and get suggestions for both variables, then I add the t and only see suggestion for insertText because of the VSCode filtering on the label. However, when I set filterText, the behavior is as I would expect.

It would be helpful to clarify this in the spec, so I filed microsoft/language-server-protocol#729.

@urandom
Copy link

urandom commented Apr 23, 2019

This also seems to be breaking LanguageClient-neovim as well

@stamblerre stamblerre mentioned this issue Apr 24, 2019
Closed
@gopherbot gopherbot added the gopls Issues related to the Go language server, gopls. label Apr 24, 2019
@stamblerre
Copy link
Contributor

Fixed as of https://golang.org/cl/176958.

@golang golang locked and limited conversation to collaborators May 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@urandom @stamblerre @gopherbot @muirdm