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?

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.

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.