Auto-complete keyword root only

[codingKerensa]

Would be great if the auto-complete had an keyboard combination to just complete the keyword currently being typed. i.e just the word before a period.

Example: I'm wanting to type case fooBarVeryLongNameHere.unusual

I start typing case foo... and the auto-complete suggestions are:

• fooBarVeryLongNameHere.commonX
• fooBarVeryLongNameHere.commonY
• fooBarVeryLongNameHere.commonZ

.**unusual** is not listed - which is absolutely fine! The suggestions are good for the most part, and the nearest match should be at the top of the list.

Describe the solution you'd like But could there not be a keyboard combination just to complete fooBarVeryLongNameHere? Perhaps something like Ctrl+{PERIOD}, or Shift+ENTER?

This feature request was on the main repo first, but I was redirected to the extension repo.

[hyangah]

Can you please provide your current settings relevant to the go extension? Those starting with "go", "[go]", "gopls" prefixes.

[codingKerensa]

Is that from settings.json? Not much, but here it is:

"go.toolsGopath": "/home/user/.local/bin/gobin",
"go.useLanguageServer": true,
"go.coverOnTestPackage": false,

Go extension version: 0.14.1 Vscode version: 1.44.2 Go version: go1.14.2 linux/amd64

[stamblerre]

Thanks for clarifying! I think you may be running into a gopls bug, since the fooBarVeryLongNameHere completion should definitely show up. Inside of a case statement, we rank based on the type being switched on - in this case, are all the fields of the same type?

/cc @muirdm for deep completions

[muirdm]

Can you provide steps to reproduce the issue?

[codingKerensa]

Updated my gopls yesterday, and can now, longer reproduce where the keyword is not included in the list. Now fooBarVeryLongNameHere does show up as the bottom entry of the list. That takes care of any bug :-) I thought the previous behaviour was by design.

So since they keyword is now listed there may little need for my specific feature request. Many thanks for your time.

Complentary info, if still needed...: In this case all the fields were of the same type. One specific example (although with a shorter keyword was this code from Learn Go with tests - Reflection. Starting to write case r... did not include reflect:

func walk(x interface{}, fn func(input string)) {
    val := getValue(x)

    var getField func(int) reflect.Value

    switch val.Kind() {
    case reflect.String:
        fn(val.String())
    case reflect.Struct:
        numberOfValues = val.NumField()
        getField = val.Field
    case reflect.Slice, reflect.Array:
        numberOfValues = val.Len()
        getField = val.Index
    case reflect.Map:
        for _, key := range val.MapKeys() {
            walk(val.MapIndex(key).Interface(), fn)
        }
    case reflect.Chan:
        for v, ok := val.Recv(); ok; v, ok = val.Recv() {    
            walk(v.Interface(), fn)
        }
    case reflect.Func:
        valFnResult := val.Call(nil)
        for _, res := range valFnResult {
            walk(res.Interface(), fn)
        }
    }
}

[muirdm]

Regarding your original post, if you want "fooBarVeryLongNameHere.unusual" you can just type something like "fooBarunu" to fuzzily match straight to what you want. This is faster than first completing to "fooBarVeryLongNameHere" and then to "unusual".

Starting to write case r... did not include reflect:

The code as written does not complete because gopls doesn't know the type of val because getValue is not defined. If you make it clear val is a reflect.Value, then the case statements complete well.

[codingKerensa]

Ah, I see... I did read about that fuzzy match, but I guess I forgot. That solves it, I believe. Thanks! :-)