settings: create one setting to specify an alternate language server

[stamblerre]

Right now, users can specify alternative tools for VS Code Go to use through the go.alternateTools setting. Both "gopls" and "go-langserver" can be replaced, which makes for a confusing user experience. What is the expected behavior if both of these are configured?

I propose that we create one setting for the language server specifically, something like:

"go.alternateTools": {
    "language-server": "gopls"
}

Where "gopls" might be the default, "go-langserver" is another option, and any other text is also allowed.

@ramya-rao-a, @hyangah: What do you think?

[hyangah]

+1 for refactoring.

I wonder if go.useLanguageServer should be enum instead of a bool.

go.alternateTools can be used to specify a wrapper script or an absolute path to the corresponding binary (for example, you can utilize this to test or ensure the use of a different version of gopls without uninstalling or installing the gopls binary from the PATH) so depending on go.alternateTools['...'] to be gopls and go-langserver should be done carefully.

[ramya-rao-a]

Both "gopls" and "go-langserver" can be replaced, which makes for a confusing user experience. What is the expected behavior if both of these are configured?

Today, if the "alternate tool" set for gopls exists, then that takes precedence over the alternate tool set for go-langserver.

We are well beyond the point of supporting go-langserver. It was supported in the absence of gopls during a time when we were making the transition to using gopls. I am ok removing the support for go-langserver. If users still want to use it, they can always map gopls to go-langserver.

Regarding using something generic language-server as the "key" in go.alternateTools, I don't believe that gives us a lot of benefits for the amount of overhead supporting it would add

[ramya-rao-a]

I wonder if go.useLanguageServer should be enum instead of a bool.

What would the enum support?

[stamblerre]

I agree that adding an enum might encourage users to try go-langserver, which we shouldn't do. I think that my PR (#3029) will achieve what we want for now, which is to only run go-langserver if the user sets it as an alternate tool for gopls. I didn't make the change to using the generic "language-server" configuration, so I am fine leaving it as is.

[hyangah]

@ramya-rao-a

I wonder if go.useLanguageServer should be enum instead of a bool.

That was based on the assumption that there is still interest or good use of go-langserver instead of gopls. In the current code, the choice of the language server is implicit so I thought the enum like the lint option would be more explicit. However, it seems the assumption is no longer true.