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

x/tools/gopls: show unimported completions for symbol names #38528

Open
stamblerre opened this issue Apr 19, 2020 · 2 comments
Open

x/tools/gopls: show unimported completions for symbol names #38528

stamblerre opened this issue Apr 19, 2020 · 2 comments
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.

Comments

@stamblerre
Copy link
Contributor

See the original discussion on microsoft/vscode-go#1846.

/cc @heschik @muirdm

@stamblerre stamblerre added this to the gopls/v0.5.0 milestone Apr 19, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Apr 19, 2020
@muirdm
Copy link

muirdm commented Apr 19, 2020

It's easy enable deep completions for unimported (but loaded) packages, but I think it will take a bit more work to make it useful in practice. I tried this out a while ago and it was just junk unimported candidates when I didn't want them, and not the right unimported candidates when I did want them.

I imagine the main challenges will be:

  1. Searching for completions across all workspace packages will be relatively slow.
  2. There will be too many matching candidates (e.g. there might easily be 10+ packages that have an exported function matching "Print"). In the vacuum of an empty "main.go" it looks amazing to complete straight to "fmt.Println", but in the context of a medium sized project, false positive and false negatives will be the norm.
  3. There will often be normal lexical deep completion candidates that also match the query. Currently we return up to three deep completions, and these unimported deep completions will be competing with lexical deep completions for spots.

Some thoughts off the top of my head:

  1. When loading workspace packages, keep track of usage counts for exported objects. When searching for completions, we first consider often used packages/objects (and stop searching once we have found X candidates). We could also use this data to rank unimported packages themselves (and other things like suggest commonly used import aliases).
  2. Require the user's query to match the unimported package name. For example, to get "fmt.Print" the user would need to type "fpri", where the "f" matches "fmt". This makes the feature harder to use/discover, but would help avoid false positives/negatives.
  3. Add one or two additional deep completion result slots reserved for unimported candidates. Perhaps reduce lexical deep completions to just two items and have one slot reserved for the best unimported candidate.

@myitcv
Copy link
Member

myitcv commented Apr 19, 2020

The linked issue mentions potentially merging the results of workspace symbol. Not commenting on the sense/viability of such a thing, but rather just flagging that I'm currently working on a refactor of the workspace symbol piece.

@stamblerre stamblerre removed this from the gopls/v0.5.0 milestone Jun 24, 2020
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants