Emmet: Unknown abbreviations no longer get expanded in suggestion list

[vvs]

• VSCode Version: Code - Insiders 1.15.0-insider (9a308d1, 2017-07-19T06:40:44.535Z)
• OS Version: Windows_NT ia32 10.0.15063
• Extensions:

Extension	Author (truncated)	Version
Bookmarks	ale	0.15.2
project-manager	ale	0.18.1
vscode-eslint	dba	1.2.11
gitlens	eam	4.3.1
EditorConfig	Edi	0.9.4
beautify	Hoo	1.1.1
atom-keybindings	ms-	2.9.1
stylelint	shi	0.27.0

---

Steps to Reproduce:

1. Open an HTML file
2. type div and then TAB. The result: incident-detail-view
3. type span and then TAB. The result: nothing happens (space is added).

[vvs]

git bisect showed me that the regression was introduced in 44072eb.

Some more bad examples:

• p and then TAB => <param name="" value=""> instead of <p></p>
• stuff and then TAB = > stuff instead of <stuff></stuff>

etc.

[ramya-rao-a]

First off, in the new emmet model tab shouldn't be expected to do emmet expansions. Read https://code.visualstudio.com/updates/v1_13#_emmet-abbreviation-expansion-in-suggestion-list

In the new model, either the user can bind a new keybinding to the editor.emmet.action.expandAbbreviation or make use of the emmet expansion in the suggestion list or use the Emmet: Expand Abbreviation command from the command pallet

Now coming to the issue at hand.

The below is from the Emmet Cheatsheet and is the case you are referring to

What we noticed when providing the above case in the suggestion list is that everything you type can now be considered an "unknown abbreviation" and will be attempted to expand which becomes severe noise when you are typing simple text and try to hit tab or enter to get indentation or a newline respectively. This is discussed in #30265

As a solution that, I am trying out not providing foo -> <foo></foo> in the suggestion list.
This will still continue to work if you use the Emmet: Expand Abbreviation command or use a new keybinding for it.

All abbreviations and snippets will continue to work as before and will appear in the suggestion list.

I agree that this will take some unlearning to do, but emmet is so much more than just foo-> <foo></foo>. Event though majority of the users might be doing only that.

If you have any other ideas to get around the noise issue in #30265, I am all ears 👂

And thanks for providing feedback. I have observed you have been chiming in, in other emmet issues as well. I really appreciate all the feedback I am getting. 👏

[vvs]

Thank you for the detailed explanation, now I better understand the dilemma. Indeed, depending on the context a user could expect different results by performing exactly the same actions.

When I type <div and then TAB, I most certainly don't want it to expand to <<div></div>. But when I type just div, then I do expect <div></div>.... Hmmm.

Actually, I like that Emmet is less intrusive now and it doesn't expand everything. Typing <div cl now I am correctly presented with suggestion <div class="", no the rather senseless <div <cl></cl>. :)

As a simple solution to 90% of problems, can I suggest to make Emmet "know" the most important abbreviations that we use every day hundreds of times? Like div, and span and p at the very least?

It is very weird when I type div and it is not expanded, one of the most frequently used tags. Please note that things like div. and span# are being expanded by Emmet properly, but not the bare bones div or span

[ramya-rao-a]

When I type <div and then TAB, I most certainly don't want it to expand to <

This has been fixed in the latest Insiders. <div will get completed to <div></div>

Typing <div cl now I am correctly presented with suggestion <div class="", no the rather senseless <div . :)

Exactly!

Please note that things like div. and span# are being expanded by Emmet properly

Yes because the logic I have identifies it as a possible abbreviation since it is not just letters.

As a simple solution to 90% of problems, can I suggest to make Emmet "know" the most important abbreviations

We could have a whitelist, but as HTML specifications change, this will be hard to maintain. But its a good place to start nevertheless.

cc @niichie, @smlombardi from #30265 for their thoughts

[vvs]

We could have a whitelist, but as HTML specifications change, this will be hard to maintain.

Yeah, but covering the most important tags would handle 95% of the cases with 5% of effort, I think.

Here's my list of must haves:

• div
• span
• p (without this, p would expand to <param name="" value="">)
• b (without this, b would expand to <base href="">)
• i (without this, i would expand to <iframe src="" frameborder="0"></iframe>)
• body
• head
• ul
• ol
• li

[niichie]

@vvs My current solution to expanding the common html tags is to use the HTML Snippets plugin, as is handles pretty much all of that for me without having to touch any emmet settings. I can understand not wanting to do this however. By doing so it allows certain abbreviations like p and b (athough you should be using strong 😛) to take priority over the emmet abbreviations.

One thing I will say it is very strange that p is defaulting to the emmet abbreviation for <param name="" value"" because according to the cheatsheet the abbreviation for that is param. The previous emmet update was supposed to only show emmet expansion suggestions when the entire abbreviation matches and I can reproduce this in a blank document.

Weirdly enough this isn't happening once I have a boilerplate down?

And here are some more examples of strange emmet behavior that I could reproduce from @vvs example

b is expanding to base href="" when the emmet abbreviation should be base

Once again not happening in the body of a boilerplate.

cc @niichie, @smlombardi from #30265 for their thoughts

I think there is definitely some inconsistency at the moment. For example h1 is being suggested as an emmet abbreviation, although it is not really one according to the cheatsheet.

I think adding some basic abbreviations like

• h*
• div
• span
• p
• ul
• ol
• li

would be useful since most people won't be typing those words in common text anyways so emmet would not intrude in most cases.

[vvs]

@niichie I can confirm that the suggestions are being different depending on the place in the HTML file!

When inside the html tags, then b expands to nothing:

<html>
  b
</html> 

When outside the html tags, b expands via Emmet to:

<html>
  
</html> 
<base href="">

[ramya-rao-a]

Thanks for testing @vvs and @niichie !

suggestions being different when typing on the last line of the document vs anywhere in the middle

Fixed with microsoft/vscode-emmet-helper@781bf99

I really ought to write test cases for this helper module before the next release is out ...

adding commonly used tags

Fixed with microsoft/vscode-emmet-helper@d230b55

h1 getting expanded to <h1></h1> even if it isn't a one of the abbreviations in the cheatsheet

Good point. ul>li is not a one of the abbreviations in the cheat sheet either, but it is a valid abbreviation nevertheless because of the > operator. And so my check was a bit relaxed. If you typed just letters, then I check if it is one of the abbreviations, else I assume you were typing an abbreviation.

Fixed with microsoft/vscode-emmet-helper@772bca6

[ramya-rao-a]

it is very strange that p is defaulting to the emmet abbreviation for <param name="" value"" because according to the cheatsheet the abbreviation for that is param. The previous emmet update was supposed to only show emmet expansion suggestions when the entire abbreviation matches and I can reproduce this in a blank document.

So in html, there are 2 kinds of emmet auto-completions that will be shown
One that expands exactly what you have typed, say a -> <a href=""></a>
The other kind is more educational, telling you what other abbreviations exist that start with the letters you have typed. a -> a:link, a:mail, area etc.

That's why you see param show up when you type p along with pic, picture etc. all of which are emmet abbreviations.

You can turn this off by setting emmet.showAbbreviationSuggestions to false

I wonder if this feature is causing more harm than help.

Thoughts?

[niichie]

I turned it off, and it does indeed fix that issue. I have however noticed that certain emmet abbreviations don't seem to currently be working.

For example select+ should expand to <select name="" id=""> <option value=""></option>

however it does not seem to be doing anything.

[ramya-rao-a]

See emmetio/atom-plugin#27 for select+
Its an upstream issue

[niichie]

Oddly enough, select+ is working for me in atom with emmet-simplified.

[ramya-rao-a]

Am not sure what you mean by "emmet-simplified"

In the new emmet plugin for atom that @sergeche is working on, you will see that it doesnt work

[niichie]

Hm, I have the emmet plugin and it seems to work?

[vvs]

@ramya-rao-a Excellent updates, thank you very much!

I noticed one problem with the following though:

adding commonly used tags
Fixed with microsoft/vscode-emmet-helper@d230b55

Some of the tags are not being expanded, even though they are listed in the source.

For example: span, body, html, ul, head are not being expanded.

I added console.log into the emmetHelper.js, and I see that doComplete() method is not even called for, say, span!

So, when I start typing s, sp, spa, span, I see that the method is invoked for s, sp, spa, but not for span.

For span though, I am presented with the text suggestion "span", not with the emmet suggestion:

This seems to be depending on the existence of the span elements in the document.

P.S. Without regression tests this would drive you crazy sooner or later though! :)

[sergeche]

@niichie you’re using old Atom plugin, the new is here: https://github.com/emmetio/atom-plugin

[niichie]

@sergeche Ah, thank you!

[ramya-rao-a]

@vvs Are you running VS Code from source?

[vvs]

@ramya-rao-a Yes, I just did:

• git pull
• scripts\npm.bat install
• npm run watch
• scripts\code.bat --disable-extensions

And I am getting pretty pointless (but funny) suggestion when I type span in the file, showed above, it suggest span itself, so this is a NOOP.

To get the Emmet suggestion (<span></span>), I have to type span then press <BACKSPACE> then n.

[ramya-rao-a]

well, thats just plain ridiculous :)

Is the problem only with span? How about other white listed tags in microsoft/vscode-emmet-helper@d230b55?

[vvs]

@ramya-rao-a I tested this on the freshly updated Insiders.

Here's my file:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Document</title>
</head>
<body>
  <div class="div"></div>
  <span class="span"></span>
  <p class="p"></p>
  <b class="b"></b>
  <i class="i"></i>
  <ol class="ol"></ol>
  <li class="li"></li>
  <script></script>

  <!-- will try the commonly used tags expansions below this line-->

</body>
</html>

So far, the following commonly used tags, listed in microsoft/vscode-emmet-helper@d230b55, are not working:

• span (tries to expand to span, via non-Emmet suggestion, marked with 'abc' label)
• body (tries to expand to body, via non-Emmet suggestion)
• ul (tries to expand to X-UA-Compatible, via non-Emmet suggestion)
• head (tries to expand to head, via non-Emmet suggestion)

[ramya-rao-a]

@vvs I had editor.wordBasedSuggestions turned off, thats why I couldn't repro.

Take the case of head, Here is what happened

• Type h, you get suggestions for emmet snippets starting with h
• Type he he is not a valid abbreviation, neither it is a commonly used tag and no emmet snippets start with he. So no suggestions from emmet
• Type hea Since there are no suggestions from any of the registered completion providers, VS Code tries to do text based completion and so gives you head because it sees that the word "head" is already in the document
• Type head Since VS Code already determined there are no suggestions for hea, it will stop calling any of the registered providers. So emmet completion provider doesn't get called.

Solution: Provide head as a suggestion when h is typed.

Fixed with microsoft/vscode-emmet-helper@600b5dc

(Phew!)