Autocompletion should have fallback to simple matching

[atombender]

Atom has a nice behaviour where autocompletion can fall back to a simple string-matching mode that matches terms within the same document, which is extremely useful to reduce typing even though there's no grammar.

In my opinion, this should be available even when the current scope has a grammar, such as Go. For example, one thing I do all the time is write a call to a function before I've defined that function. So I'll do something like:

func main() {
  loadDataFromFile()
}

// Then I start typing:
func loadD

Even though there's no function loadDataFromFile defined yet, the autocompletion should offer it as a match for loadD, because it's in the file. (Having a "create function loadDataFromFile" command at the call site would obviously be even better, but this is just one example of many.)

This kind of autocompletion is also super useful in purely-plaintext or other non-grammatical scopes, including comments, Markdown, and so on.

[jrieken]

We do exactly that. When a higher ranked completion provider doesn't return a result we fallback to word-based completions.

Assigning to @ramya-rao-a to make sure vscode-go actually returns nothing in that case

[atombender]

Is this a grammar-specific deficiency, then? Or regression? Or something I have accidentally turned off? Because it doesn't work anywhere. I get zero string-based autocompletions anywhere — I've tried plaintext, Markdown, YAML, Ruby, JavaScript and Go.

[jrieken]

Most likely, the setting is called editor.wordBasedSuggestions.

[atombender]

Not touched that setting; it's on. I think there's one or more extensions that are screwing with the built-in suggestion system.

I just disabled all the plugins and found that enabling this one breaks everything. I'm going to see if there are any other extensions that also break things.

[jrieken]

Reopening to understand how that is possible. Extensions shouldn't have the power to stop word-based suggestions...

[jrieken]

There is bug on our side that we don't but the completion provider from auto filename into the same bucket as the word-based provider.

[atombender]

Nice, thanks.

[atombender]

@jrieken I encountered another problem which I'm not sure whether is a regression or something specific to snippet handling, or what. With vscode-go I'm not seeing the fallback to simple string matching if I type func before what I'm autocompleting. For example, this works:

type Bing = 1
B  // <-- Pressing Tab here will suggest "Bing"

Whereas this doesn't:

type Bing = 1
func B  // <-- Pressing Tab here will not suggest "Bing"

Is this snippet functionality (func is a snippet) interfering with autocompletion? Do I submit a bug here or vscode-go?

[ramya-rao-a]

@atombender

func being a snippet will not interfere when text is typed after func

I tried your example (replaced B with X because typing "B" gives bool and bytes as suggestions from the Go extension's completion provider and so fallback to simple string matching could not be tested)

I was able to get the right suggestions in both cases.

What are your settings?

[atombender]

@ramya-rao-a This is weird, it was absolutely not working for me the other day for one specific use case, and I thought my test case reproduced it... but now I can't reproduce it the way I thought I did. It might be a special edge case, but of course I can't remember what file I was working in either.

However, my comment above has a syntax error, which reveals another edge case (which may or may not be the same one):

Notice the syntax error.

I don't think the autocomplete is falling back to string matching at all, or it would have shown the string from the declaration that contains the syntax error. Notice, by the way, how it affects type declarations but not constants:

Obviously this is not a real use case, but I often edit a file with syntax errors (because I'm in the middle of shuffling things around, copying and pasting and so on), and I expect autocompletion to be consistent even then.

[ramya-rao-a]

@atombender

In your first case where you get bool, builtinattrs and byte as suggestions, there will be no fall back to string matching because the completion provider from Go extension has provided the 3 suggestions. As @jrieken mentioned earlier, the fallback to string matching occurs when there are no suggestions from any of the registered completion provider.

In the second case, where syntax errors result in missing suggestions, this would be a bug on the gocode tool that is used by the Go extension to provide completions. Why syntax errors in type declarations cause different behavior compared to constants can be best explained by the gocode author. Can you open an issue in the gocode repo?

[atombender]

But that's my point — string matching should always be included, no matter what the extension has provided.

I don't consider gocode to be in error here; I think it's sensible that it leaves out names that are ill-defined. Some errors are presumably completely unrecoverable; for example, an unclosed /* would cause the entire remainder of the file to become non-Go. I think the problems are independent of gocode.

But I'm afraid I don't understand the string-matching heuristics at all. For example, if I have this:

// frobnitz

func something() {
  frolick := true
}

fr <caret>

Here, fr doesn't offer any completions, but if I hit ctrl-space, it does offer the string matches. That's very mysterious to me.

[ramya-rao-a]

Here, fr doesn't offer any completions, but if I hit ctrl-space, it does offer the string matches. That's very mysterious to me.

I see this too.

@jrieken Basically there are 2 questions here

1. Why not include string based matching even when there is a completion provider returning suggestions?
2. String based matching sometimes appear only after hitting Ctrl-Space and not just typing

[atombender]

Thanks. Just to point out (as noted before), your first bullet point also encompasses snippets, which why I mentioned this earlier.

Here, there are three oddities:

1. Autocompletion dropdown doesn't appear until Ctrl-Space, and then it only suggests a snippet, no string match. Is that because it's offered by the extension?
2. Autocompletion does appear right after func b, but not thereafter. So func b will offer a snippet without Ctrl-Space, but func bl is silent. Only one-character function names offer a snippet.
3. Nothing happens if I select the snippet (vscode-go bug?). I find it odd that it suggests a snippet like that; it's guessed some odd arguments. If I got to a different file and type func foo and hit Ctrl-Space, no snippet is suggested.

Again, difficult to see where one bug begins and another starts. There might be several issues here.

[jrieken]

Why not include string based matching even when there is a completion provider returning suggestions?

Each provider gets a rank depending on the selector it uses when registering. The word based provider usually has the lowest score and the rule is that lower ranked providers aren't asked if higher ranked providers produced a result. That is to avoid duplicates and spam.

String based matching sometimes appear only after hitting Ctrl-Space and not just typing

Depends. When a provider registers trigger characters like . only those providers are queried after those character. Otherwise or when completion is explicitly requested all providers are queried, however always following the rules outlined above