Support for choices in Emmet snippets

[ramya-rao-a]

We now have support for choices in snippets via #17545

But these choices don't show up in Emmet snippets. For example the transform snippet as defined here: https://github.com/emmetio/snippets/blob/v0.2.5/css.json#L178

[ramya-rao-a]

The syntax for choices in snippets as supported by VS Code and as used by Emmet (https://github.com/emmetio/snippets/blob/v0.2.5/css.json#L178) are very different.

Plus, the main selling point of Emmet abbreviations is the brevity and the ability to get the snippets with the least amount of clicks.

The main issue that was the reason of creating this current issue was that snippets like trf:x would not get expanded as expected.

I reasoned that will snippet choices, we can surface this. But now I don't think that snippet choices is the right solution here.

On digging deeper, I found the root cause for trf:x not expanding as expected to be that the logic that finds best match in Emmet 2.0 is case sensitive.

So trf:X would expand as expected, but trf:x wouldn't

I have logged an upstream issue for this: emmetio/css-snippets-resolver#6

[ramya-rao-a]

Pushed a fix to ignore case when fuzzy matching,

So trf:rx will now rightly expand to transform: rotateX(angle)

Note to verifiers:

From the css section in the emmet cheatsheet try out any of the abbreviations which have :

[ramya-rao-a]

cc @LukeMcGurdy

[roblourens]

In bds:n the n doesn't expand to none like the cheatsheet says it should. Probably not a vscode issue though.

[roblourens]

Do you know where the first n suggestion comes from? Annoying to have to go past that for emmet. This is with --disable-extensions