VS Code Completion of Provider Types could be more helpful

[afscrome]

Bicep version
VS Code 0.3.255

Is your feature request related to a problem? Please describe.

I've encountered several instances where the autocompletion for resource types is not as ueful as it could perhaps be. These could be seperate issues, but they are related so I'm posting them as one issue.

For longer resource types, code completion starts to become problematic due as the resource names get truncated.

In this first example, I have a long list of options but as they're all truncated to a common prefix, I have no idea what the difference between the options really are

In this second example there are two problems

1. I've fully completed the Microsoft.Insights/ prefix, however there is a bunch of noise for other Microsoft.*.Insights resources. Given that I've already fully qualified Microsoft.Insights/, I'd expect suggestions to be limited to Microsoft.Insights/*
2. This example is a worst case length where at first glance it seems like you have a full api version, but in reality the -preview has been truncated away.

In this third example, I want to provision a storage container, so I type container to get auto completions. The first several results are overwhelmed by several different versions of ACI / ACR resources, but what I actually want is Microsoft.Storage/storageAccount/blobServices/container - I have to scroll through 10 pages of autocompletion before coming across this.

Describe the solution you'd like

I think the ultimate problem is that bicep is complete the entire resource@version string in a one go - maybe it would make more sense to up the auto completion into a few segments. My first thought was something like C# where you only complete one segment at a time (e.g. up to the next / or @). However that removes the explorability of providers were you could just type container and find the fully qualified name Microsoft.Storage/storageAccount/blobServices/container - I imagine something between these two extremes would work.

[miqm]

Dup #1060

[alex-frankel]

I think realistically this needs to be addressed with #622 with some type aliasing solution. They type strings are just too long and complex today.

Segmenting out the intellisense would also improve this if we cannot fully address it with aliasing.

[alex-frankel]

If you are eager, looks like @TarunSunkaraneni implemented some of this already in an open PR :)

You can download vscode-bicep.vsix from this action run and install it:

1. Open VSCode.
2. In the Extensions tab, select the options (...) menu in the top right corner and select 'Install from VSIX'. Provide the path to the VSIX file you downloaded.
3. Click "Install".

[slapointe]

Two part resource type completion is available in the latest release (v0.3.539) and I must say that it work very well for me.

It is a good improvement

[afscrome]

Yup, agreed two part completion is a big improvement. container still does seem to have some oddities with auto completion - some of these suggestions are interesting

[TSunny007]

VSCode edit distance algorithm has a mind of its own, and i'd be interested in refining this experience. Would having a ranking system that orders using the longest overlapping string, then ranking by total edit distance be an appropriate solution to this?

[TSunny007]

Ah, didn't catch that this was quite a scroll down from the obvious completions. The search algorithm used here is VSCode's default logic, which VSCode uses in typescript and probably many other extensions. While i understand that sometimes the matching behavior of VSCode is peculiar, as long as the most logical matches show up at the top of the list it's probably not worth the effort to implement a search algorithm that won't cause regressions