Closed
Description
Suggested in microsoft/vscode-go#2918.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
{{ message }}
No one assigned
No type
No projects
No milestone
None yet
Activity
muirdm commentedon Nov 27, 2019
Is there a use case for this once unimported completions are enabled by default? The only case I can think of is manually correcting an (incorrect) ambiguous import, but even that should be pretty rare.
heschi commentedon Nov 27, 2019
I agree the justification for this is weak. Maybe if you're exploring an import hierarchy, like you can't remember the exact package name you're looking for but you know what repo it was in?
stamblerre commentedon Nov 27, 2019
@heschik: That's what I was thinking. Definitely not pressing, but I thought it wasn't a bad idea.
nbaztec commentedon Dec 20, 2019
I can try to take a look into this one, if someone can point me in the right direction so as where to take a look. Thanks!
We too have long import names, of which sometimes only a part is valid, eg:
github.com/foo/bar/my-super-valid-name/v1/lib/httpand an autocompletion would certainly be of helpmuirdm commentedon Dec 20, 2019
Another not-mutually-exclusive option is to make unimported package name completion match against the full package path instead of just the package name (i.e. completing package names in the code, not in import specs). Using your example path, the user could type
supervalid<>to see unimported packages whose path fuzzily matches "supervalid", orsupervalidhttp<>to complete straight to the desired package. This way the user can explore things without resorting to manually futzing with the import spec.19 remaining items
gopherbot commentedon Aug 27, 2020
Change https://golang.org/cl/251086 mentions this issue:
internal/lsp/cache: don't invalidate metadata for new invalid importsmuirdm commentedon Aug 27, 2020
Ah, okay.
Maybe it is worth it to do a simple/fast
go list -find <pkg>call on the modified import to first see if it exists? Additionally, if it is already a "known" package path we could skip the additional "go list -find" call and proceed with the full metadata refresh.stamblerre commentedon Aug 27, 2020
Oh that's a great suggestion - let me try it out. We can also detect if the change is on-disk or not, so we can avoid a ton of
go listcalls when a user changes branches.stamblerre commentedon Aug 27, 2020
Ah, actually unfortunately, I don't think we'll be able to do that. I completely forgot that
go listmight download things, so any invalid package path will takego lista long time, and we can't afford to do that while a user types.stamblerre commentedon Aug 27, 2020
We may be able to use known packages to see if the user is typing a package path within the main module, but that may be error prone. Something to consider in a follow-up.
internal/lsp/cache: don't invalidate metadata for new invalid imports
stamblerre commentedon Aug 31, 2020
@heschik has suggested that we might try loading with
GOPROXY=offby default so that the package.Loads are not prohibitively slow. I think a lot of our logic will have to change if #40728 is accepted, so I'd say that it's not worth making any changes until we know what the behavior ofgo listwill be like in 1.16. Then, we make any necessary changes in a cohesive way.heschi commentedon Sep 1, 2020
For the record, I think the
go mod tidycode lens is also getting involved.dandua98 commentedon Sep 12, 2020
@stamblerre should we close this issue and open new issues for import label and cursor placement? I think it would make it easy to track those bugs.
gopherbot commentedon Sep 17, 2020
Change https://golang.org/cl/255837 mentions this issue:
internal/lsp/source/completion: improve import suggestion labels