microsoft / vscode-go

An extension for VS Code which provides support for the Go language. We have moved to https://github.com/golang/vscode-go

Other

5.93k stars 648 forks source link

Support the 'List Package declarations' feature from GoSublime #671

Closed winxxp closed 4 years ago

winxxp commented 7 years ago

Do have a plan to support: 'Browse Declarations', 'Browse Files', 'Browse Package', 'List File declarations', 'List Package declarations'? This is the GoSublime provided very practical features.

ramya-rao-a commented 7 years ago

For some of the features you listed, we have VS Code counterparts that do similar if not the exact same thing

List File declarations -> File Outline (Ctrl + Shift +O) gives file declarations in the order they appear in the file
Browse Declarations -> Workspace Symbol Search (Ctrl + T) and start typing. This will search symbols in the workspace. Browse Declarations lets you browse through ALL packages whereas the Workspace Symbol Search lets you search through packages in the current workspace
Browse Files -> Ctrl+P and you search for files in the current workspace

Things that are missing

Browse Packages
List Package Declarations

PRs are welcome for the missing features, but there is no work currently active around this.

ramya-rao-a commented 7 years ago

330 covers browsing selected package

ramya-rao-a commented 5 years ago

The only thing left is the List Package Declarations feature.

PRs are most welcome to implement this feature. Is anyone aware of any Go tool that can list all the package symbols given a package?

kentquirk commented 5 years ago

Well, if you do something like this:

cd mypkg
go build -o TMPFILE.o
go tool nm TMPFILE.o -type |grep " T "   #that's space-T-space
rm TMPFILE.o

You'll get something that looks like the set of publicly defined symbols in the pkg.

But you have to build the package and generate an object file in order to get that, and it's decorated with stuff the linker needs cares about that you'll have to strip off. It's probably not the right solution but it might point someone else to it.

ramya-rao-a commented 5 years ago

@kentquirk That's interesting. You are right though, if we have some other way of getting the information, I would choose that.

One option is to use go list to get the list of Go files in the package, then run the go-outline tool for each to get the symbols. But I'd rather use a tool that does this in one go, instead of having to be invoked for each file.

Question: For this feature, would we care mainly for exported symbols or all symbols? I would think just the exported symbols.

anacrolix commented 5 years ago

@ramya-rao-a definitely all symbols. The feature is for developers to move around a code base, there are other Go tools for checking the external API of a package already.

stamblerre commented 4 years ago

Will the LSP workspace symbol satisfy the requirements here? gopls has just added support for this request.

ramya-rao-a commented 4 years ago

@stamblerre The workspace symbol as part of LSP works at the workspace level where as the request for List Package Declarations scopes the same to current package

stamblerre commented 4 years ago

I think that workspace symbols combined with document outline should be enough to meet the needs here, so I'm inclined not to add this extra feature. Maybe we can reconsider if there is a lot of support for this, but new features should be added via the LSP, and this is not a LSP feature.

ramya-rao-a commented 4 years ago

Workspace symbols when the package is opened as the root folder would give this exact same feature as well, so I agree with your assesment.