commit 2adf828841459f00f0514ff37c7fa54aae9e5e06
author Muir Manders <muir@mnd.rs> Tue Aug 13 13:45:19 2019 -0700
committer Rebecca Stambler <rstambler@golang.org> Wed Aug 14 16:13:50 2019 +0000
tree 954057fc9a35ba14e842145e9975d35131119109
parent 9dba7caff850354a6238aa8121bf3c338e6696ba

internal/lsp: add fuzzy completion matching

Make use of the existing fuzzy matcher to perform server side fuzzy
completion matching. Previously the server did exact prefix matching
for completion candidates and left fancy filtering to the
client. Having the server do fuzzy matching has two main benefits:

- Deep completions now update as you type. The completion candidates
  returned to the client are marked "incomplete", causing the client
  to refresh the candidates after every keystroke. This lets the
  server pick the most relevant set of deep completion candidates.
- All editors get fuzzy matching for free. VSCode has fuzzy matching
  out of the box, but some editors either don't provide it, or it can
  be difficult to set up.

I modified the fuzzy matcher to allow matches where the input doesn't
match the final segment of the candidate. For example, previously "ab"
would not match "abc.def" because the "b" in "ab" did not match the
final segment "def". I can see how this is useful when the text
matching happens in a vacuum and candidate's final segment is the most
specific part. But, in our case, we have various other methods to
order candidates, so we don't want to exclude them just because the
final segment doesn't match. For example, if we know our candidate
needs to be type "context.Context" and "foo.ctx" is of the right type,
we want to suggest "foo.ctx" as soon as the user starts inputting
"foo", even though "foo" doesn't match "ctx" at all.

Note that fuzzy matching is behind the "useDeepCompletions" config
flag for the time being.

Change-Id: Ic7674f0cf885af770c30daef472f2e3c5ac4db78
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190099
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>