Configure selector keys for suggest widget

[csholmq]

Whenever suggest widget (e.g. a completion list) is summoned (by a configured trigger character, e.g. . or >), both Tab and Enter are valid for selection by default. More than once I've accidentally accepted the suggestion rather than doing a line break as intended.

https://github.com/mitaki28/vscode-clang/issues/8 is a good example of this where a completionProvider is configured and triggered by >, causing issues when trying to do a line break:

At first I thought I'd suggest that the default should be only Tab to avoid all of this. But then I came to think that perhaps more ideally this should be configurable by the extension that registers a provider with triggerCharacters. What do you think?

[joaomoreno]

It's already part of the registerCompetionItemProvider signature.

[csholmq]

@joaomoreno Could you elaborate? Can't find anything on this.

Just so we're talking about the same thing. Yes, triggerCharacters are in the signature. But the issue is about

When a completionItemProvider is called upon and a suggestion widget is presented, which keys (default Tab and Enter) are allowed as confirmation of a suggestion. Would be preferable to disable Enter as this can interfere.

[joaomoreno]

Oh! Apologies, I confused the two features!

[joaomoreno]

Removing Enter from the acceptance keys would make the whole interaction rather strange, though. I'm not sure that would be such a good idea.

You'd type person-> get it triggered and you wouldn't be able to use Enter?

There are other possibilities here:

• delay the popup of the Intellisense box when automatically triggered
• disable > as a trigger character; not a nice solution as well
• improve the suggestion results to not return anything in some cases; not a nice solution either

[csholmq]

I agree that the convention of Enter might not be so popular to remove.

template <typename Type>
Type max(Type a, Type b) {
    return a > b ? a : b;
}

is perhaps a more valid example for e.g. C++. Other languages have for sure syntaxes which could collide with completion trigger characters. It depends on the coding style of the programmer in this instance. It might also come in play when you do an anonymous function calls (lambda abstraction):

context.subscriptions.push(vscode.workspace.onDidSaveTextDocument(d => 
    ...
    yourMagicCode();
    ...
));

• Delay is dubious since one will suspect that no completions are available if it's set to more than a second.
• Disable the offender is a ugly workaround IMO. It removes functionality.
• Agreed. Sounds complicated as it's no longer language agnostic.

That is why I'm suggesting that each provider with trigger characters should be able to override the default mapped keys for acceptQuickFixSuggestion.

[joaomoreno]

So a C++ user could never use the Enter key to accept a suggestion? I'm not sure that is OK.

I do recognise the problem though.

@stevencl any thoughts?

[csholmq]

A C++ could very well be able to use this. I'm just suggesting that this choice is left for the extension to control and ultimately by the end user which configures the extension. It all depends on the preferences of the user base. As it stands now, the "only" solution is to disable Enter as a shortcut for all extensions and languages.

[stevencl]

Is it possible to trigger on a string, or sequence of characters? So instead of triggering on '>' we would trigger on '->' for C++?

[csholmq]

@stevencl That's actually a nice workaround. At least for languages with -> as member operators.

[joaomoreno]

ping @jrieken

[jrieken]

Currently there is no way to configure a trigger sequence but only single characters. Still, the issue would continue to exist as most people run with 24x7 IntelliSense enabled. I tend to favour an option that configures if enter should accept a suggestion or not - for simplicity and ease of learning independent of the language.

[jrieken]

see #1657 for more on this

[jrieken]

closing this as a duplicate of #1657 as we will go down the path of configuring what Enter does