[Go] Missing `punctuation.accessor` scope after typing a dot

[imax9000]

What happened?

Minimal example to reproduce:

package main

import "fmt"

func main() {
    fmt.
}

When the cursor is right after the dot, punctuation.accessor scope is not present, so the default auto-complete trigger for it doesn't work:

Curiously, that scope is present before the dot (but only if the dot is already there):

I'm currently using stable channel, build 4180.

[deathaxe]

The "Scope Name" popup displayes scope of tokens after carets. Hence first screenshot displays scope of whitespace after the . token. Only . token is scoped punctuation.accessor, but obviously not the whitespace after - per design.

Scopes are applied as expected.

Completions are correctly triggered when typing . in SAFE MODE.

Maybe a plugin is resetting it. LSP for instance adjusts auto_complete_triggers to what it gets from language servers.

[imax9000]

The "Scope Name" popup displayes scope of tokens after carets. Hence first screenshot displays scope of whitespace after the . token. Only . token is scoped punctuation.accessor, but obviously not the whitespace after - per design.

Scopes are applied as expected.

Completions are correctly triggered when typing . in SAFE MODE.

Maybe a plugin is resetting it. LSP for instance adjusts auto_complete_triggers to what it gets from language servers.

I've changed auto_complete_selector to "meta.tag, source variable, source constant" and completion wasn't triggering for me. (default value of "meta.tag, source - comment - string.quoted.double.block - string.quoted.single.block - string.unquoted.heredoc" over-zealous to my taste)

[deathaxe]

List item values are fully overridden. So it's likely you just removed . trigger.

[imax9000]

List item values are fully overridden. So it's likely you just removed . trigger.

Hmm, interesting. I did not have auto_complete_triggers override in my config when I encountered this issue. And now I can't reproduce it on my setup 🫠

I'll keep an eye out if I notice it misbehaving again.

[deathaxe]

Anyway, it wouldn't be related with syntax packages.