/cc @dandua98

https://go-review.googlesource.com/c/tools/+/258322 should resolve this. I always assumed c.item calls c.matcher.Score to validate an item for prefix (or fuzzy match) but I guess not. In fact, we only call c.matcher.Score in some places so wonder if there are similar issues with other completions on emacs and other clients. VSCode ignores completions not matching prefix by default so that's why I never saw this. /cc @heschik

Regarding using an exact prefix match instead of fuzzy match, technically we weren't using any match at all right now (as mentioned above) so hopefully this resolves it. We should respect user defaults unless agreed that comment completion should override and use only prefix match.

... possible requiring a minimum prefix match length (e.g. no comment completions unless exact prefix match at least three characters)

I don't think this would work with current LSP spec. I believe you currently have comment suggestions enabled all the time (what LSP spec calls 24/7 completion) instead of invoked (like ctrl + space). The LSP spec recognizes both these triggers as of the kind Invoked (see https://microsoft.github.io/language-server-protocol/specification#textDocument_completion), so there's no way to distinguish between them. When manually invoked by a user (using ctrl+space), we should show all completions and not have a set matching requirement like matching 3 characters, but that also means we can't support this for always on completion. Hopefully the LSP spec would distinguish between these cases at some point.

When manually invoked by a user (using ctrl+space), we should show all completions and not have a set matching requirement like matching 3 characters

I don't agree. I don't see any problem with returning no completions until we are confident the user actually wants completions. With comment completions as they are, the overwhelming majority of completions are false positives since most words I'm typing are not identifiers from the code.

If manually invoked, the user definitely wants completions. That's why they invoked them in comments, right?

If manually invoked, the user definitely wants completions.

Good point.

For me, having unwanted completions pop up as I'm composing comments greatly outweighs having false negative completions. Anyway, I can always disable it in my editor if I don't like it.

Anyway, I can always disable it in my editor if I don't like it.

Was curious what you meant by this. Do you mean you can configure your editor to disable 'always on' completions in comments?

Do you mean you can configure your editor to disable 'always on' completions in comments?

I meant I would disable all comment completions.

Closing this since the prefix issue was resolved by https://go-review.googlesource.com/c/tools/+/258322. The other issue mentioned here depends on if microsoft/language-server-protocol#1101 is addressed at some point in the future.