Counter-intuitive "editor.suggestSelection" behavior when completion is "kept open"

[Gama11]

• VSCode Version: 1.25
• OS Version: Windows 10

In the Haxe extension, we want to support the following two use cases:

• identifier.| - request completion for the fields within identifier.
• some.package.| - filter packages / types by the dot path that's currently being typed. In this case, the completion items don't change when typing a dot, so the suggest widget should simple be kept open (but filtered accordingly).

To support of the first use case, we need to register "." as a trigger character, which means that provideCompletionItems() is invoked for the other case as well, even though it wouldn't be necessary there. But so far so good, we can simply return the same completion items again to keep the suggest widget open, and adjust the range of the items to match against the entire dot path typed so far.

Here's a simple extension that simulates that:

'use strict';
import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
    vscode.languages.registerCompletionItemProvider('plaintext', {
        provideCompletionItems(doc, pos, token, context) {
            var range = new vscode.Range(new vscode.Position(0, 0), pos);
            if (doc.getText(range) == "Json.") {
                return [
                    {label: "parse"},
                    {label: "stringify"}
                ];
            }
            return [
                {label: "haxe", range: range},
                {label: "haxe.ds", range: range},
                {label: "haxe.ds.Map", range: range},
                {label: "haxe.ds.BalancedTree", range: range},
                {label: "Json - haxe.Json", insertText: "Json", range: range}
            ];
        }
    }, ".");
}

This approach actually works quite well, but it causes an annoying interaction with the default behavior of "editor.suggestSelection" (default is recentlyUsed). If the Json - haxe.Json entry has been selected before, it is auto-selected when typing the dot in haxe.:

This might not look like a big issue there, but with many completion items between the packages and haxe.Json it's more problematic. The packages you were just filtering against are now scrolled totally out of view:

Of course, this can be worked around with "editor.suggestSelection": "first", but that's not a great experience for our users. preselect: true also doesn't seem to help. Even if that's set for the "haxe.ds" item in the sample code above, the Json item is still auto-selected on haxe.|.

I think the underlying issue here is that there isn't really a concept of "keeping the completion open / leaving the results unchanged", so VSCode thinks "ah, there were results, so this is must be a new completion and the "editor.suggestSelection" logic should be applied". Could the intention of keeping completion open be detected implicitly somehow, perhaps by comparing the previous to the current provideCompletionItems() result? If so, the "editor.suggestSelection": "recentlyUsed" step could be skipped in those cases.

[jrieken]

Could the intention of keeping completion open be detected implicitly somehow, perhaps by comparing the previous to the current provideCompletionItems() result? If so, the "editor.suggestSelection": "recentlyUsed" step could be skipped in those cases.

Hm, sounds interesting... We have the concept of a completion session which is triggered and then filtered. Ignoring the suggest memory when filtering is in reach and would work, I am just worried about potential user confusion. We can run give it a try and check what feedback comes in

[Gama11]

For what it's worth, suddenly jumping to a different position in the completion list mid-filtering causes quite a bit of user confusion too. :) Not sure if the change could have any unintended side effects though.

[jrieken]

stretch for July...

[gjsjohnmurray]

I'm interested in this. Can it be a backlog candidate?