Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: fuzzy completion does not return result when expected #38380

Open
myitcv opened this issue Apr 11, 2020 · 4 comments
Open

x/tools/gopls: fuzzy completion does not return result when expected #38380

myitcv opened this issue Apr 11, 2020 · 4 comments

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented Apr 11, 2020

What version of Go are you using (go version)?

$ go version
go version devel +801cd7c84d Thu Apr 2 09:00:44 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools v0.0.0-20200408225201-7e808beafd9f
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools/gopls v0.0.0-20200408225201-7e808beafd9f

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.vim/plugged/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build227804233=/tmp/go-build -gno-record-gcc-switches"

What did you do?

-- go.mod --
module github.com/myitcv/playground

go 1.12
-- main.go --
package main

import (
	"fmt"
)

func main() {
	fmt.Prnf
}

What did you expect to see?

Triggering completion at the end of fmt.Prnf to return a single result, fmt.Printf

What did you see instead?

Triggering completion at the end of fmt.Prnf did not return any results.

See the following gopls log: bad.log


cc @stamblerre @muirdm

FYI @leitzler

@gopherbot gopherbot added this to the Unreleased milestone Apr 11, 2020
@gopherbot gopherbot added the Tools label Apr 11, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.0 Apr 11, 2020
@muirdm
Copy link

@muirdm muirdm commented Apr 12, 2020

This is due to how the fuzzy scoring works. Non-initial, non-connected letters ("n" and "f" in "Prnf") get a big penalty. In your example, the penalized "n" and "f" outweigh the "Pr" causing the candidate not to match. Normally the user is not filtering using in-between letters.

"Printf" in particular is unlucky since "f" represents another word "Formatted", but "f" is lowercase so the fuzzy matcher doesn't know it is an important letter the user might want to use to filter results. If it was named "PrintF", for example, then it would work better.

@myitcv
Copy link
Member Author

@myitcv myitcv commented Apr 14, 2020

This is due to how the fuzzy scoring works.

Can you provide a bit of background on the thought process? Because it's somewhat strange (to me at least) that this doesn't match at all: a lower score, maybe, but no match?

My perspective, FWIW, is shaped by other fuzzy finders, like fzf

@muirdm
Copy link

@muirdm muirdm commented Apr 14, 2020

Unfortunately I don't have any more background because I didn't write the gopls fuzzy matcher.

This is the check that counts a match with two short, non-initial matches as poor.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 14, 2020

Our fuzzy matcher is adapted from a library used internally at Google, and it handles multiple languages, which may account for some of the cases that don't work as expected for Go. I don't think we will prioritize significant modifications / improvements to this library in the near future, so if anyone has a suggestion for an alternative well-supported fuzzy matching package, we can use that (much like we did for go-diff). Otherwise, we can continue to use this package with small bug fixes as needed, until we have time to prioritize this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.