@aeschli might be something we want to fix for April.

@jrieken the JSON provider returns a CompletionList with an empty array of items.
If I understand right that should prevent the textual proposals to show up.

@jrieken Maybe it would make sense to make the 'showTextualProposals' a setting on CompletionList.
It's more explicit. It would also allow to have your own proposals together with textual proposals

Actually, I was wrong about the empty array, falsy values and the empty array are considered to be a not good result which means delegate to next level of suggest. This is the defined behaviour and should be like this ever since JSON became an extension.

Suggest works by keeping an ordered chain of providers and goes through them until one produces a result. In the scenario here, the schema apparently says there are zero completion for this property. That makes the next provider become active. Because it's a system of fairness I don't want to allow a provider to block/disable all providers that come after him just because he didn't yield a result - that's a no to flags ala showTextualProposals and isComplete etc.

I think the meta question here is what do you expect from IntelliSense? Is it about deriving text from a set of rules (grammar, schemas, etc) or about typing faster with suggestions ranging from correct to useful?

It might just boil down to personal preference and looking at the sample above I see two camps

• You trust the JSON brain/schema and if there are no proposals there is nothing more to type
• You use suggestion as a tool to quickly type, ideally correct code, but the validation will let you know about it later anyways

Personally, I am clearly in the latter fraction but I understand how people might not like that. So, I believe what it takes is a user setting to control how the empty array returned by a completion provider is to be interpreted - as empty result or invite to continue in the chain.

The delegation rules will be then

• undefined or null returned ➡️ delegate to next provider
• [] returned ➡️ delegate or done based on user setting

I think both mindsets (bullet points) above make sense, and I can certainly see a case for both scenarios. Personally I enjoy the "strictness" of JSON schema, but I can see how "useful-but-not-entirely-accurate" auto-completion provides some value also. User-configurable sounds like a good way to go.

Thanks for working on this.

The new settings will be called, smartSuggestionsOnly and defaults to false.

@jrieken @egamma @aeschli

I have mixed feelings about a smartSuggestionsOnly, mostly due to the smart part of it. Its explanation also doesn't help: Controls if less smart suggestions show up when a language service cannot compute them. Are the users who have this problem really going to find this setting?

I think we should think about textual suggestions as an exception to the rule and create a setting for controlling that exception, instead of considering it to be another link in the suggestion chain; and a dumb one for that matter.

I'd propose instead to go with a wordSuggestions setting with 3 possible values: never, default, always. I'd further propose its explanation to be: Provide suggestions based on all the words of the current document. By default, they are shown only when no further suggestions are provided (by a language service, for example)..

+1 for Joao's proposal. But IMO the default should be that the language specific completion support can choose when textual completions are appropriate, as @alexandrudima mentioned. In the case of JSON, that would be inside comments and strings.
At all other places, completing a word where a string literal is requested (with quotes) doesn't make sense, it leads to syntactically incorrect JSON and makes the JSON support look bad.
As mentioned above, I'd suggest to add a new flag includeTextualProposalsto the CompletionList(which is the result of a completion processor). The flag would be or'ed across all contributed providers, and if one of them responded true, textual proposals are included.

The explanation of the wordSuggestions option would be:
Provide suggestions based on all the words of the current document. By default, word completions are shown if no language specific completion support is present or when a completion support considers word proposals to be useful.

That will IMO please the two user camps described by Joh:

• You trust the JSON brain/schema and if there are no proposals there is nothing more to type: default
• You use suggestion as a tool to quickly type, ideally correct code, but the validation will let you know about it later anyways: always

@joaomoreno I am not against making the textual suggest logic configurable and 'yes' what you propose can replace the new config setting. Tho if we decide to take it out of the chain of providers and treat it special we will not ever be able to move textual suggestion logic into an extension. Something I though is desirable but also willing to give up.

@aeschli No to includeTextualProposals because that's just one completion item kind and there are many others, think of snippets to which we face a similar challenge. Also, that's the opposite of a collaborative system

@jrieken includeTextualProposals would be additive (or'ed) in that when at least one (active) provider sets it, the textual proposals will be added. Same collaborative spirit as when we make a union of all proposals of all (active) providers.

The problem is that it would also need includeSnippetProposals, includeXYZProposals etc. So the thing to set would be or'ed completion item kind. Next question is if this is just a recommendation or a contract/filter. Then the question is why does the provider compute valid completion item kinds at a position but not the completion items? It seems we make things more complex than necessary.

It is a recommendation. If set by at least one provider and the wordSuggestions is 'default' (or 'enabled'), the textual proposal provider will be included.
Why does the provider not compute the textual proposals itself? So it doesn't need to know about the 'wordSuggestions' settings. Also if there are multiple providers that set includeTextualProposals to true, the work is only done once.
Snippets could work the same way. wordSuggestions setting and a includeSnippetProposals flag. Or 'snippetContext', if we choose to add context to snippets. But I thought we wanted to have this discussion rather next week.

But I thought we wanted to have this discussion rather next week.

Yes, but I don't want to fix one problem is a special way includeTextualProposals when there is another very similar problem.

I have revert the change and I am opting to move this to May cos this is too much controversy for an endgame fix.

As input for the discussion: The problem with always, default, and never is that people that set it to never won't get completions in documents for which no language service exists. I don't think that's desirable. Also, never can be confusing cos textual suggestion can also come from a language service meaning someone that has set it to never can still see suggestions with kind text.

Well, never means never, no matter whether a language service exists or otherwise. I think it covers it pretty well.

As for the second part, I think that is quite alright. A dictionary extension can always send out suggestions with kind text. What the setting addresses is the collection of words that can be found in the current document.

Well, never means never, no matter whether a language service exists or otherwise. I think it covers it pretty well.

That's my point. It's a difference to get textual completions in places where a language service didn't compute any (like discussed here) and not getting any suggestions ever in files that lack a language service. The settings must differentiate these two cases, otherwise we simply move textual completions into an extension and tell people to uninstall it.

Well, that's what the default would be for.

IMO that's an oversimplification that let's just agree to disagree.

No need to throw hands in the air. I don't disagree with you, I'm just having problems with the arguments against the setting. In fact, I would be willing to bet that I am the one that is missing some detail(s) here.

Remember that my approach was laid out in my first comment: I think about textual suggestions as an exception to the rule. Given that viewpoint, the three possible values seem to fit every use case, don't they? You are either never interested in textual suggestions, always interested in them or only interested in them if no one else has anything better to present, hence the default case. What am I missing here?

Yes, you can implement the same behaviour by putting textual completions into an extension and tell people to disable them. But what good would that do?

What am I missing here?

IMO this: Someone doesn't like textual suggestions in JSON and turns the setting to never. He then opens a XYZ file and doesn't get any completions because there is no language service and textual completions are disabled. User is unhappy.

Yeah, but isn't that just settings scoped by language, for which we are long due?

Editorconfig solves a lot of that, but not everything. For instance, I also dislike auto suggestions in some languages, and would like to disable them, although I do like it in others.

Yeah, that's one option

There is now editor.wordBasedSuggestions taking a boolean to turn off/on word-based suggestions.