x/tools/gopls: improve suggestions in completion placeholders

[stamblerre]

Context: #31547.

We should suggest in-scope identifiers of the matching type when adding placeholders for a function.

We would also need to develop some heuristics to determine which identifier to suggest, if there are multiple in scope. (Ideas: most recently declared, closest name to the one declared in the function signature.)

[muirdm]

Edit: this comment doesn't make sense. Snippets are part of textDocument/completion, and if the user isn't using snippets we shouldn't complete with any extra stuff.

Another (not necessarily mutually exclusive) option is to put function argument smarts in textDocument/completion rather than snippets. That way even when you aren't using snippets you can benefit from smart arg suggestions. Snippets are an "I'm feeling lucky" situation, so having the wrong suggestion in there could be mildly counter productive in certain cases.

[muirdm]

I looked briefly at using "completionItem/resolve" to fill in placeholders with actual completion items. It is doable, but a bit inconvenient. We could also try doing it in the original completion request for all candidates, but it might end up being too slow.

Another approach is for gopls to return empty placeholders and have the editor automatically trigger a completion at each tab stop. This would be ideal because it is no extra work for gopls and gives the best user experience. However, I think every editor would need to be updated to allow for automatic triggering of completion at (empty) placeholders.

VSCode has "editor.action.triggerSuggest" but I don't think it will work for multi-placeholder snippets. One workaround to not require editor changes might be to trigger placeholder completions piecemeal:

1. Complete foo.Bar(a int, b string) to foo.Bar(<>)
2. Automatically trigger completion at <>
3. When user accepts completion, insert another snippet with a comma leading to next parameter, e.g. foo.Bar(myInt, <>)
4. Automatically trigger completion at <>
5. Repeat as necessary for more parameters.

I kind if like this idea since currently it can be overwhelming to get a giant function snippet with a bunch of long arguments. This would declutter things and let the user focus on one argument at a time. However it would conflict with the current use of "editor.action.triggerParameterHints".