Fuzzy auto-complete does not work

[poga]

When I type rents in Ruby code, auto-complete can provide suggestion as render_to_string.
However, if I type RegHa in Go code. it does not provide suggestion RegisterHandler.

Typing Reg does show suggestion as "RegisterHandler", so I guess it's related to fuzzy string matching?

[joefitzgerald]

gocode is providing the suggestions. It doesn't do fuzzy matching; it only matches on exact matches for the prefix.

[tylerstillwater]

According to nsf/gocode#51, @nsf is explicitly not providing fuzzy matching, leaving it up to whomever is using gocode. It would seem this is something go-plus needs to do. As he says:

And regarding sorting, it is perfectly possible for an editor to request all completion variants and sort them as it wishes: fuzzy matching, case insensitive matching, regexp matching, anything you want. Ask goclipse guys.

What would need to happen for this to become a feature of go-plus? I am trying to move to Atom from ST3, and I've come to realize just how much I rely on fuzzy matching, as well as how jarring it is to no longer have it.

[nsf]

As for me, I'm using Atom now as well. I can see go-plus doing autocompletion request for every character you type when autocompletion is active. Maybe it's not the best idea ever. I've implemented autocompletion in my own editor, the logic was something like that: When user requests autocompletion, query gocode, then keep that list around and remove it only when user's cursor is behind or ahead of the request point or if the user typed characters that do not match any of the autocompletion candidates. Which means I do filtering on my own. I think all editors should do that. :)

Plus atom has a built-in fuzzy matching lib called fuzzaldrin: https://github.com/atom/fuzzaldrin

[joefitzgerald]

Fuzzy matching is built into the default autocomplete provider (SymbolProvider) and so will always be available as a fallback. When I rewrote autocomplete-plus, we built in a debounce so that keystroke performance is not impacted by ac+ dispatching requests to ac+ providers - provided those providers are asynchronous (go-plus is).

I could fuzzy match against the suggestions gocode provides me but that seems redundant - gocode knows better than any fuzzy matching, after it has been run.

I've not had anyone give me evidence (I.e. With a chrome profile image) that go-plus is impacting performance because of its gocode integration.

Is there a specific functional gap here? What, functionally, is missing? ac+ will fuzzy match if gocode does not provide any suggestions. Gocode knows better than a fuzzy matching algorithm if it does run.

[tylerstillwater]

For me, it's a matter of speed and convenience. Coming from ST3, it is rather well ingrained in me to type only specific parts of a function call I am trying to insert. For example fmt.pl becomes fmt.Println, fmt.pf is fmt.Printf, etc. For every function I want to call, I can simply type the first character of each "word" in the function name and I will almost always get the correct result.

gocode is certainly more accurate and exact, but fuzzy matching within the gocode results lets me move more quickly.

[nsf]

And I don't use fuzzy matching for autocompletions. But I guess it would be nice to have it as an option.

[a13xb]

I could fuzzy match against the suggestions gocode provides me but that seems redundant - gocode knows better than any fuzzy matching, after it has been run.

@joefitzgerald I don't think these are mutually exclusive. You still could have fuzzy matching on top of gocode results. It speeds up typing verbose function names I can't be bothered spelling out.

[joefitzgerald]

I'm open to pull requests @a13xb

[joefitzgerald]

Take a look at v5.8.3.