x/tools/gopls: make a decision about the CLI

[adonovan]

gopls has a command-line interface that exposes many useful pieces of server functionality (e.g. show analysis diagnostics, rename an identifier) in a form that can be easily invoked from a shell script or other program. Since we no longer support the older separate CLI tools (e.g. gorename), there is a case to be made that should be a first-class interface. However, it is currently nominally "experimental".

The task of this issue is to:
(a) figure out roughly how many people use the CLI tool in its current form. Telemetry should make this easy.
(b) decide whether to publish a stable, coherent, and well-documented set of command-line operations, and, if so,
(c) build and document it.

Another possibility we should consider is whether to provide a pure LSP client (I am guessing such a thing exists) that knows nothing of gopls. This may be less work overall and may align better with standard client-side ways of doing things, though it's also possible that it's more verbose, or clunky, or just can't easily express all the things we would like it to do.

[findleyr]

We already have a headless LSP client for our regression tests (and, indeed, another slightly less robust headless client for the current command line interface).

IMO it would be more generally useful to extract this as a general purpose command-line interface for LSP servers. If we maintain the current CLI and regression tests we are effectively maintaining a headless client anyway, so why not share it in a more useful way?

[adonovan]

IMO it would be more generally useful to extract this as a general purpose command-line interface for LSP servers. If we maintain the current CLI and regression tests we are effectively maintaining a headless client anyway, so why not share it in a more useful way?

It would certainly be more useful, but I wonder who would actually use it, and how much additional burden it would impose to attempt to remain strictly server-agnostic or to deal with the quirks of more than one actual server. It might also make it harder to use with gopls, and, by being in a separate executable, might introduce IPC or version skew issues that we can ignore in the current approach. I'm not opposed, but we should go into it with a clear understanding of the costs and benefits.

[muirdm]

I imagine custom features of the CLI would also be useful to Go specific editor modes wanting tight integration. Maybe custom behavior could be kept organized as LSP actions (or whatever they are called) which could be presented on the gopls CLI as "native" operations, but still accessible from generic LSP clients. If you tried to use one of these custom operations against a non-gopls server, you would get a <whatever> action not supported error.

[candita]

For the record, I wanted to try out gopls but my IDE of choice (JetBrains GoLand) doesn't seem to implement it. I'm trying it out from the CLI and would be happy to hear you made a decision in favor of keeping a CLI.