@hyangah suggested that we could use code lenses to offer the user an option to start a local godoc server.

Another code lens feature VS Code Go provides is 'run test' and 'debug test' code actions. They are currently through a separate GoDocumentSymbolProvider that invokes go-outliner underneath. Would be nice if gopls provides the code action as well.

I'm keen to give the run test code lens a try. I currently have a basic implementation that uses a command (much like the go generate code lens does) to run the test.
The question now is what we want to do with the output of that command, as it stands now I just call ShowMessage with test passed or test failed based on the output of the command, but maybe we want to show the full output of the test somewhere (if it fails). Any ideas about this last point?

That's awesome @martskins - please do send a changelist when you're ready :) I think the show message is fine for now (we do something similar for go generate here). You can also use the progress reporting, which I believe gives access to the output channel.

Ideally, we'd be able to write to the VS Code output channel like the extension does, but LSP doesn't support that yet. Looks like @marwan-at-work, who wrote the go generate code lens, has already filed that request: microsoft/language-server-protocol#945.

Running tests is tricker than running go generate because if the tests fail, you really wanna look at why a test fails (especially if you're running table tests or package-level tests, you wanna know which test exactly failed)

In go generate we are using the WorkDoneProgress UI (which only shows one log at a time and disappears right away) so the tests won't work for that.

go generate however falls back to the gopls window-output if WorkDoneProgress is not supported by the editor.

The problem with the gopls window-output is twofold:

1. You can't have the LSP tell the Client to "show the window now" -- so the user must know how to find it.

2. That window is cluttered with LSP specific logs (for a good reason ) and even the go-generate output is actually specially formatted for the LSP Inspector.

So from VSCode's perspective, using that will actually be a much less friendly user experience than what's currently in place until the proposal Rebecca mentioned is accepted and implemented in clients.

I believe it was mentioned to me at some point that you can do custom requests and each client will have to implement that custom request, so that's another route but im not familiar with it :)

For VS Code, there is also 'debug test' code lens that works closely with the debugger. I expect that will be hard to delegate to gopls. For VS Code, we will probably end up using this as a hint to detect 'Test*', 'Benchmark*' functions and test command arguments. Then, translate it back to our own VS Code commands from lsp middleware, instead of delegating the test run to gopls.

As a vim user I would say that I would find it useful to be able to run tests delegating it to gopls, even if it doesn't output the failure message. I understand that this is far from ideal though. But being able to at least check that the tests still pass is a pretty decent addition.

The idea to use VS Code (or vim, or you name it) itself to run the tests sounds to me as a decent compromise until that proposal is accepted though.

@martskins in VSCode, we already have this implemented on the plugin-level and it uses output channels appropriately. So it would be a step backwards in terms of user experience in VSCode.

Would it be possible for gopls to toggle this on/off so that vim users can turn it on and VSCode users can turn it off? Preferably automagically 😄

@martskins in VSCode, we already have this implemented on the plugin-level and it uses output channels appropriately. So it would be a step backwards in terms of user experience in VSCode.

Would it be possible for gopls to toggle this on/off so that vim users can turn it on and VSCode users can turn it off? Preferably automagically 😄

Yeah, the plan is to have this feature be off by default until it reaches parity with VS Code. (See more detail in @findleyr's comment on https://golang.org/cl/231959).

We have many lenses now. What's left to do?

I would say that the remaining work is to check which code lenses VS Code supports, so that we can try to reach feature parity. Also, we could add the code lens @hyangah suggested in #36787 (comment).

vscode-go plans to utilize gopls's codelens by replacing the commands
with vscode-go native commands, from our language client middleware.

List of codelenses currently offered by vscode-go. (@mcjcloud)

• ‘run package tests’ -> ‘go.test.package’
• ‘run file tests’ -> ‘go.test.file’
• ‘run package benchmarks’ -> ‘go.benchmark.package’
• ‘run file benchmarks’ -> ‘go.benchmark.file’
• ‘run test’ -> ‘go.test.cursor’
• ‘debug test’ -> ‘go.debug.cursor’
• ‘run benchmark’ -> ‘go.benchmark.cursor’. (cl/243159)
• ‘debug benchmark’ -> ‘go.debug.cursor’

Codelenses with open feature requests

• 'run main` code lens: add a 'run' code lens for main functions vscode-go#159
• 'debug main'
• 'show doc' (?)

Change https://golang.org/cl/245358 mentions this issue: src/goLanguageServer.ts: add "debug test" and "debug benchmark" codelens

vscode-go plans to utilize gopls's codelens by replacing the commands
with vscode-go native commands, from our language client middleware.

List of codelenses currently offered by vscode-go. (@mcjcloud)

• ‘run package tests’ -> ‘go.test.package’
• ‘run file tests’ -> ‘go.test.file’
• ‘run package benchmarks’ -> ‘go.benchmark.package’
• ‘run file benchmarks’ -> ‘go.benchmark.file’
• ‘run test’ -> ‘go.test.cursor’
• ‘debug test’ -> ‘go.debug.cursor’
• ‘run benchmark’ -> ‘go.benchmark.cursor’. (cl/243159)
• ‘debug benchmark’ -> ‘go.debug.cursor’

Codelenses with open feature requests

• 'run main` golang/vscode-go#159
• 'debug main'
• 'show doc' (?)

The "debug test" and "debug benchmark" code lens will be available with gopls enabled as of https://golang.org/cl/245358.

Change https://golang.org/cl/246017 mentions this issue: lsp/code_lens.go: add "run file bencharks" code lens

Can add "which interfaces are implemented" code lens?
It's just like:

0 references | impl Writer
func (devNull) Write(p []byte) (int, error) {
	return len(p), nil
}

I'd love to see a code lense to similar to guru's freevars command.

rust-analyzer has already a good support on codelens, it'll be good to see it lands in gopls as it's super useful.

rust-analyzer codelens references/implementations

with codelsn info provided by rust-analyzer (calculated based on cursor position) , I can easily debug rust test item in vim using vimspector and vimspector config:

test
rust-analyzer codelens test

debug
rust-analyzer codelens debug with vimspector

currently it's a pain to debug go in neovim