Vscode: Completion Item Providers are no longer triggered automatically inside "" (quotation marks) in html language mode

[andersea]

Hi, I am the author of HTML Class Suggestions. After 1.11 was released I got a report (andersea/HTMLClassSuggestionsVSCode#9) from a Mac user, that the extension was no longer working. After testing this myself I could confirm that it didn't work on either my Windows PC or my Kubuntu laptop either.

After some debugging, it would seem that the trigger behaviour for calling the completion item provider for html has changed in 1.11 compared to previous versions. If you are inside quotation marks (""), meaning that you are editing an html attribute value, then VS Code no longer triggers code completions.

You can trigger the completions manually with ctrl+space, but this is pretty annoying since it did work fine before.

As a programmatic workaround, I have found that if you add an array of specific completion characters as trigger characters (so all of a-z) then the completion provider is called. This is not a good workaround however, because it will override the build-in completions completely, so you no longer get completions for normal html, like div, input and table tags or for attributes.

• VSCode Version: 1.11.1
• OS Version: All

Steps to Reproduce:

1. Install VS Code 1.11
2. Install HTML Class Suggestions extension.
3. Create a new project folder.
4. Add some css (download bootstrap and unpack it into the project.)
5. Create a html file
6. Type (assuming bootstrap) <div class="con

In VS Code 1.10 this triggers the extension to deliver completions from css that starts with "con". (You can downgrade to 1.10 to verify this.) This no longer happens in 1.11.

[jrieken]

Yes, we have changed the default for when 24x7 IntelliSense is triggered. Many people complained about it being too aggressive in comments and strings. Manually invoking IntelliSense or invoking via a trigger character still works. You can also customise the setting as described here: https://code.visualstudio.com/updates/v1_11#_intellisense-in-comments

[andersea]

This breaks not just my extension, but all the other class lookup extensions as well. Zignds extension has a quater of a million downloads. You just broke all of them.

[jrieken]

Sorry, we weren't aware of that, but we were just looking a numerous, equally emotional, complains about suggestions everywhere in strings and comments. I'll bring it up for discussion

[jrieken]

We will not make a candidate fix for 1.11.2. It seems mostly html/xml-users are affected by this change. We will keep an ear open and we can always change the default for either html or all languages to have 24x7 Intellisense in strings.

Until then, the old behaviour can be restored with this configuration

"editor.quickSuggestions": {
    "comments": false,
    "strings": true,
    "other": true,
}

[0xEAB]

Maybe this strings shouldn't be treat as such. One could introduce a new _markup language string (mlstring)_ type.

If this new type were used for HTML, XML ... files, all those broken extension could target that one, while quick suggestions for normal strings could stay disabled.