I'm sympathetic when the editor won't do what we want. In my case, the Typescript behavior is infuriating: i almost always want to call the function whose name is being completed. If I want just the function name a simple backspace throws the parens away. On the other hand, if there's a profusion of user settings it's hard to find the one (if it's only one) to change. It would be nice if the editor would just adapt to each user's behavior, but getting there seems very hard.

I'd suggest using an existing option to key off of instead of adding a new one, but unfortunately there's no "existing" option in VSCode to build off of, because VSCode doesn't anticipate this interaction model at all. The closest is "editor.autoClosingBrackets" which "controls whether the editor should automatically close brackets after the user adds an opening bracket."

And this is the problem; the whole VSCode experience is built around the idea that you're going to type that bracket yourself - indeed, the whole Visual Studio tool set. If I open up a .py file in VSCode and type pri<tab> it completes to print, and not print(). If I open up a C# project in Visual Studio (not code), and type in this.Equ<tab>, it replaces it with this.Equals, and not this.Equals(). I'm sure it's fine if you only write Golang code, but having one language behave differently than tall the others is... not fun.

While I agree - in most cases - less options is better, in this case the golang plugin is the one actively fighting against the "established norm" in VSCode. So if we want to not have an option, that's fine, but I'd argue in this case we should fix the golang plugin to start behaving like all other languages do, and just not add the ()s. If we're going to keep the auto ()s, then the golang plugin should add an option so those of us long time Visual Studio users who are set in our ways can at least make it behave sensibly (and I'd strongly argue the default for that option should be to not auto-add the ()).

You can disable the parens by disabling snippets (this will disable all gopls snippets, which may or may not be what you want). I don't know in particular how to configure VSCode to disable gopls snippets.

@muirdom Could you please elaborate on this workaround? How would you disable snippets? I don't see any options to disable snippets in the gopls settings. Disabling snippets globally in VSCode via editor.suggest.showSnippets doesn't seem to help (but I assume this isn't what you mean anyways), nor does disabling snippets for go via:

    "[go]": {
        "editor.snippetSuggestions": "none"
    },

It is a client capability. The LSP client sets the textDocument.completion.snippetSupport capability to false (see https://microsoft.github.io/language-server-protocol/specification#textDocument_completion).

Aha. If I comment out these lines in gopls, it does indeed fix this. That does seem like kind of a sledgehammer though.

@pjweinb I've just discovered that typescript has a setting that behaves (more or less) like gopls with ui.completion.usePlaceholders turned on. If you enable the setting typescript.suggest.completeFunctionCalls in vscode, then myFun<tab> will complete to myFunction(x, y, z) with "x" selected ready to type over (and you can tab to y and z). I don't think there's a setting that will make it behave exactly like golang, though.

I think this is a dupe of #41813.

Thanks @muirdm, I agree. Closing this in favor of the earlier issue.