Vscode: Tab no longer works with Emmet

Created on 10 Aug 2017  ยท  82Comments  ยท  Source: microsoft/vscode

  • VSCode Version: Code 1.15.0 (8b95971d8cccd3afd86b35d4a0e098c189294ff2, 2017-08-09T20:06:21.685Z)
  • OS Version: Darwin x64 16.7.0
  • Extensions:

Extension|Author (truncated)|Version
---|---|---
jsx|Twe|0.0.1

Not sure why, but suddenly tab no longer triggers expansion. I see there's a menu, but no way to assign a key command to that. Not having a keyboard shortcut makes using Emmet annoying. The whole thing about Emmet is that it's suppose to be the quick way to create markup. You just made it not quick. As someone who uses Emmet every day, this is beyond annoying.


Steps to Reproduce:

1.
2.


Reproduces without extensions: Yes/No

emmet verified

Most helpful comment

The tab binding has been a staple of Emmit from day one and I would push for not changing that. Technical issues aside, the editor now fundamentally no longer works like I would expect.

All 82 comments

Tab is no longer associated with Emmet

Please read the Release Notes or the blog on Emmet 2.0

@ramya-rao-a Please at least give us the option to bind "Tab" to Emmet. "Tab" is a shortcut we've relied on across many editors for years.

@johnlindquist tab was the logical choice for all editors because it's synonymous with auto-completion/content-assist.

Now that emmet shows up in the auto-completion/content-assist, pressing tab selects emmet from the list and you get your abbreviation expansion.

Of course, if you have editor.quickSuggestions turned off, you are now forced to either press Ctrl+Space to get the suggestions or use a new key binding for the emmet command.

Is that your scenario?

Also,I am assuming you read the blog which states the issues that came out of tab being bound to emmet

Re-opening issue to continue the discussion post the 1.15 release

The tab binding has been a staple of Emmit from day one and I would push for not changing that. Technical issues aside, the editor now fundamentally no longer works like I would expect.

I do disable quickSuggestions. I personally find boxes popping up all over the place unprompted annoying, so I turn off as much as I can. I invoke autocomplete often, but on my terms.

@burkeholland

If one was to say that they don't use the suggestion widget/ content-assist, I can understand how this fundamentally changes things.

If one was using the suggestion widget/content-assist, then pressing tab still completes the abbreviation. In css, the emmet abbreviation is sorted appropriately among the css suggestions (all of which are fuzzy matched themselves). In html, the emmet abbreviation is the first one (pre-selected) that shows up in the suggestion list and so pressing tab selects the abbreviation which results in the expansion. The end result being no different than before.

Thanks for sharing that you fall under the first camp above @johnlindquist

I am interested in hearing feedback from more people.

Maybe a setting in quickSuggestions like displayOnlyTopResult or displayOnlyEmmet would be a happy middle-ground...

@johnlindquist

displayOnlyEmmet is not possible. Emmet now is an extension. And like any other extension can only say that it has suggestions to provide and no control over if there are suggestions from other extension. And VS Code cannot play favorites with extension, giving an option to show only that.

But your other suggestion of displaying only a single result is interesting,
This way you get the benefit of seeing the preview of the expansion

If you have a custom component, Foo, you have to manually invoke Emmet to expand to <Foo></Foo> now.

True, otherwise the suggestion list would keep appearing for every word that was being typed. Because technically every word is a valid abbreviation that can be expanded to <word></word>

and fwiw, it misses common tags like header/footer as well.

Update https://github.com/Microsoft/vscode-emmet-helper/issues/5 for requests for more common tags

Tabbing through an expansion like nuxt-link[to]*5 with quickSuggestions enabled is immensely frustrating. You have to escape at every single stop.

Sorry, what stops are you referring to that you need to escape? In the below gif, I keep typing (no esc) and when ready, hit the tab.

emmet

Btw, am not trying to negate your experience, just trying to understand the user experience better. I appreciate all the feedback.

It's a matter of filling out the stops and dismissing all the completion popups. Also, if you accidentally hit escape when completion doesn't popup, you have to start over.

I'm accustomed to tabbing and shift-tabbing through all the stops without even thinking about it.

The only difference I'm currently seeing is that my React components only work when there is a - in the name? Though to be fair, I'm not entirely sure if this worked before...

2017-08-10_20-44-14

@burkeholland It did work before.. Read https://github.com/Microsoft/vscode/issues/32243#issuecomment-321705997 for why simple text words do not trigger emmet suggestions

So, I looked at the documentation. Seriously??? You expect people to have to navigate through the command palette for what was a simple tab before? Do you want us to go back to Atom and Sublime? The documentation also mentions editor.action.emmet.expandAbbreviation. However, when I try to add this configuration to my settings, it gets squiggles underneath and hovering I get "Unknown configuration setting". Did anyone even try that before pushing this?

@rbiggs expandAbbreviation is a keyboard shortcut:

Thanks John, that helps. But I really don't want to be doing a three finger salute when tab was so simple. I'd like to have the option to restore Emmet abbreviation with tab. I use Emmet every day, through out the day. Tab saves me tons of time. I've never had a problem with it. Don't just take something away. Give us an option for those who prefer tab use for Emmet expansion.

Sorry about the mistake in the documentation, that has been corrected.
The idea was to encourage new keybinding for users who have disabled quick suggestions

I can see how heavy users of emmet never seem to have had a problem with using tab. Maybe they were real careful (or got used to) not hitting tab right after a word for indentation purpose or never had css suggestions show up and get chosen when intending to expand css emmet abbreviation (this might be because people turned off quick suggestions for css as a work around).

Or compared to the amount of emmet usage, the above 2 occurrences were too small to matter for such users

But we have seen precisely these problems from a number of users.

These new features (no tab, emmet in suggestions) have been in preview (opt-in) for over 2 months now in stable builds. And the Insiders had the new features enabled by default in these 2 months. I got to work with quite a few Emmet users and act on their feedback. Its unfortunate that no-one felt so strongly about tab being removed as the shortcut for emmet.

Is it possible to bring back tab as the keyboard shortcut for emmet and have it fall back to normal tab i.e indent when there is nothing to expand in the current released version?

You can bind tab key to editor.emmet.action.expandAbbreviation command explicitly and it will definitely work.
But if you hit tab expecting indentation in any file, you will be see with the message "Running the contributed command:'emmet.expandAbbreviation' failed.". This is because there is no fallback to provide indentation.
You can add the resourceLangId == html to the when clause in your keybinding and restrict this behavior to specific file types i.e the ones where you are using emmet.

So what's the real solution?

I can add the fallback to indenting based on the value of the setting emmet.triggerExpansionOnTab (which was deprecated in 1.15, but can be brought back). It will be false by default as opposed to true before. This is so that the issue of emmet abbreviation expanding on tab when non-emmet users are pressing tab doesnt occur. You can enable the setting and get tab -> emmet

When can we expect this solution?

We currently don't have a recovery build planned for 1.15 i.e there is no 1.15.1 planned. If we do plan such a build, then I can look into including this fix there. Else, this will be available in the Insiders build for the next version i.e 1.16 which should be out sometime next week.

As a fairly new user of vs code I really don't understand the change of this behavior. Like others have pointed out we have been relying on the tab for emmet in other editors for quite some time now.

As emmet is a way to make typing of tags and other default language stuff very fast, it feels to me that that speed is now mostly lost. As @burkeholland mentioned, it is now working in a way we don't really expect it and is causing us to be less fast in development. And quite frankly annoying me ๐Ÿ˜ž

@rbiggs another workaround is to do the following which makes it expendable by emmet (still annoying ๐Ÿ˜† )

emmet

Thanks nealoke, that helps. But I'd rather have the option to keep using tab. Otherwise, I'm going to have a terrible experience context switch from VSCode to every other editor (Atom, Sublime) that use tab for Emmet :-(.
I've been using Emmet Since it was called Zen Coding back in 2010. That's seven years of using tab to expand. I'll repeat, text editors have been supporting Emmet expansion with tab for seven years. Somehow the VSCode team decided seven years of use didn't matter. They didn't bother checking out what the use history was, what other editors were doing, or what the Emmet users expect. Bad decision.

I would also argue that Emmet being included in a list of "suggestions" is misunderstanding how Emmet is used.

Emmet is a precision tool. When I type .foo, I expect <div class="foo"></div>. There is no other expectation or suggestion, it's simply an _exact expansion_ of what I typed based on a set of pre-defined rules.

"Suggesting" an Emmet expansion is like asking, "Did you mean <div class="foo"></div>?" And the answer will always be, "Yes, of course, I typed .foo!" I would never pick another option from a list of suggestions when using Emmet, it simply makes no sense.

We are working on the option to use tab for emmet.
Should be out in our next Insiders build in a few hours.

All,

If you have VS Code Insiders, update it.
If not, then download the latest Insiders from https://code.visualstudio.com/insiders

Add setting emmet.triggerExpansionOnTab to true and you should be able to get emmet expansions on tab

Take it for a spin and let me know if it works as expected.

Looks like this is already basically resolved, but I wanted to point out that there is a setting that I don't see suggested above, "editor.wordBasedSuggestions": false, which will disable suggestions that are only based on text in the document (the ones with the abc icon).

I disable it because this is responsible for most of the noise that shows up in the suggestions box, and that shows up in some of the gifs above. With this, I never see the suggestion box pop up in an html file, except for emmet completions, so I think the experience is as close to the proposed displayOnlyEmmet option as you can get.

Looks like emmet.triggerExpansionOnTab is closer to what people expect, but disabling wordBasedSuggestions is another option, if you find the suggestions box useful!

For those having trouble with autocompleting JSX in React, a quick fix is to add "emmet.includeLanguages": {"javascript": "javascriptreact"}

Setting the editor.action.emmet.expandAbbreviation to Tab also breaks the "highlight->Tab" indent process.

@alchermd Fallback to tab when emmet is not applicable is not implemented for the new emmet in 1.15 which is why we don't recommend binding tab.

Try out the latest Insiders and set emmet.triggerExpansionOnTab to true there and tab should work with appropriate fallback

Just installed the insider's edition. And yes, now I have Emmet working the way I would expect. ๐ŸŽ‰ ๐Ÿ‘๐Ÿ‹๏ธ I suggest you put something prominent in the documentation for Emmet about how users can get the expected tab expansion back. And maybe point our any side effects this may cause for other functionality. I noticed that the only thing about Emmet in the current docs is under Languages/HTML. That makes its discoverability hard. I just spent quite a bit of time digging around to find it. And then the Emmet info is just a a short piece about snippets. Thanks for your patience and perseverance. ๐Ÿ‘๐Ÿป

@rbiggs When the recovery build (1.15.1) is ready for release, I plan to update the current Emmet blog with notes on how to get tab->Emmet working (by setting emmet.triggerExpansionOnTab to true) and its side effects.

Was finding the blog difficult too?

I was hoping for the blog to the source of truth for all things Emmet in the future.

As a developer, you expect the docs to be the one source of truth for a product. It will be up-to-date. Blogs can go stale and buried under new posts, so I don't expect blogs to have relevant information. I only ready a product blog when it comes up as a search result. Otherwise I always dig through the docs. Usually product blogs are mere announcements. Case in point, I didn't even know that blog post about Emmet existed. Developers go to the documentation. When the documentation isn't good, then they consider it a questionable product. I'm pretty sure every Emmet user is going to be digging around in your docs trying to figure out why they can't get Emmet to work. And then wind up going to stackoverflow, not to your blog post.
I notice that for Atom they have all the docs for Emmet in their section on packages, which are the same as VSCode extensions. In your case, basic Emmet support is provided out of the box, so I would expect it to be in the docs somewhere. Looking at your docs right now, I'd expect it somewhere in the User Guide section. Emmet is not a language, and it does fit in Extension Authoring or Extension Reference. My two cents.

Good points.

@gregvanl had the same thoughts about having emmet in the docs section and the blog being info for a snapshot in time.

I'll work on the docs right away.

Closing the issue as the required changes have been merged to the release branch.

Will update this issue once 1.15.1 version is released

you're joking right, tab so awesome,you deprecated,it's a big mistake!

Ramya, I think keeping it in a blog post is a big mistake. I've been using VScode since it first launched and I never, ever look in the blog. Blogs are for announcements, not documentation. Since you include Emmet by default, it needs to be in the documentation. In contrast Atom and Sublime do not include Emmet out of the box. You have to install the extension. And the extension authors provide the documentation. Blog posts are dated, and they get buried by newer posts. Documentation is the current state of support.

what a pityโ€ฆโ€ฆ

emmet.triggerExpansionOnTab is not working,because there is no emmet.triggerExpansionOnTab in vscode
emmet 2.0 config,so you can't add it in user config,it will be give you a error:unknow emmet attribute!

@sjy219 As mentioned in https://github.com/Microsoft/vscode/issues/32243#issuecomment-321961991 before, the emmet.triggerExpansionOnTab setting is available in the VS Code Insiders. You can get it from https://code.visualstudio.com/insiders

We will be releasing VS Code 1.15.1 in 2 days or so, the setting will be available there as well

Never mind, my "solution" breaks pretty much everything.

I don't understand why this was removed. The abbreviation shortcut doesn't work anyway and it's a pain in the ass to have to bring up the command palette for something that's used so incredibly often.

@TheDutchCoder Did you try any shortcut other than tab in VS Code 1.15? If you did and it didnt work, please let us know.

Else, please see https://github.com/Microsoft/vscode/issues/32243#issuecomment-322373908

Other keys work fine, though a ton of them give conflicts of course.

I have (for now) bound it to command + e, but waiting for tab to return ;)

@ramya-rao-a I code in VS Code 1.14,I will be waiting for 1.15.1.Yes ,I renew to bind tab key to emmet 2.0, and it worked,but there was a problem, there was a conflict with editor's tab,it means the editor's tab key was not working, so I don't know how to fix it, how to config "when" attribute ,may be that's the main problem!

@sjy219 Don't try to bind tab to emmet in 1.15.0. There is no fallback to editor's tab for indenting.
Either use a different key for emmet in 1.15.0 or in the latest Insiders (and the upcoming 1.15.1), set emmet.triggerExpansionOnTab to true

@ramya-rao-a I got it,waiting for the upcoming 1.15.1(1 2 3....)

@ramya-rao-a thank you very much!

@ramya-rao-a you are doing great ๐Ÿ‘ ๐Ÿ”ฅ

Waiting for next version. Remove tab from Emmet kills me.

Is it that much harder to press Enter, to confirm your emmet selection? I guess I'm just used to it, cause I didn't start using emmet until they added the improved version.
Also, it looks like the most recent update should have fixed this for everyone.

Alright people, VS Code 1.15.1 is out. Restart your VS Code windows to update.

Set emmet.triggerExpansionOnTab to true to expand Emmet abbreviations and snippets on pressing tab

The Emmet 2.0 blog has been updated to reflect the changes.

And https://code.visualstudio.com/docs/editor/emmet is the new page under docs for all things Emmet in VS Code

Thanks for your patience and Happy Coding!

Edit: Okay, so apparently now you have to use emmet.includeLanguages instead of the original emmet.syntaxProfiles, otherwise it still won't work.

I guess this changed in 1.15 as well...

@TheDutchCoder when your .foo became .footer was there a suggestion list open with .footer being suggested with the icon "abc" like below? If yes, that would be word based suggestions which you can control with editor.wordBasedSuggestions.

screen shot 2017-08-16 at 2 31 39 pm

When the suggestion list is open tab never triggered emmet before, nor will it trigger emmet now. When suggestion list is open, tab selects the first value from the suggestion list.

@ramya-rao-a I believe it did yeah. I normally ESC out of the suggestions anyway because of it.

Now emmet shows up in the suggestions, so that negates the issue (after I changed all my settings), but I might disable the word suggestions anyway, I don't really seem t use it.

Thanks!

The tab key is come back,I just want to say perfect! Thanks guys๏ผ

@ramya-rao-a I just found a small bug (in 1.15.1):

When setting emmet.triggerExpansionOnTab to true, in addition to Tab, any invocation of the expansion command will insert a tab/indent when expansion isn't available. This includes any additional keyboard shortcut that is bound to emmet.expandAbbreviation, and when you select "Emmet: Expand Abbreviation" from the command palette or the Edit menu.

I assume this is unintended.

@noinkling That's an unfortunate side effect that existed earlier as well.

You see, the code running the expansion has no knowledge of how the expand abbreviation command was triggered i.e command pallet vs keyboard shortcut. It isn't aware of which keyboard shortcut was used either. This is why the setting emmet.trigerExpansionOnTab is important. That is how the code decides to fallback to tab->indent.

Am curious, why would you have both emmet.triggerExpansionOnTab enabled and have another keyboard shortcut.

Am curious, why would you have both emmet.triggerExpansionOnTab enabled and have another keyboard shortcut.

In reality I wouldn't personally, I just came across this while playing around. Some people might like to have a second binding for when they're typing one-handed or something, I don't know ๐Ÿ˜„

This change should be marked in bold in release notes, if i didn't click on a small link pointing to list of fixed issues, i would not know what is wrong.

For about a week i was wondering what extension broke or what happened and i did not even update VSC at home, to keep my TAB working :)

but finally i can just type div then TAB it again, so much less work โ™ฅ

edit: ah, it's in release notes, but not much visible.

about this: Unexpected Emmet expansions occurring when the user wanted to just add an indent using the Tab key. - i learned to press ESC then TAB long time ago, solves this issue pretty easily :P

I can't get emmet's tab completion to work:
image
image

{
    "emmet.triggerExpansionOnTab": true,
    "html.format.wrapAttributes": "force-aligned",
    "vsicons.projectDetection.autoReload": true,
    "workbench.iconTheme": "vs-seti",
    "terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
    "window.zoomLevel": -1,
    "files.autoSave": "afterDelay",
    "editor.fontFamily": "Fira Code",
    "editor.fontLigatures": true,
    "editor.formatOnSave": true,
    "editor.tabSize": 2,
    "html.format.unformatted": "",
    "html.format.wrapLineLength": 80,
    "files.autoSaveDelay": 3000,
    "files.exclude": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/CVS": true,
        "**/.DS_Store": true,
        "**/*.js": {
            "when": "$(basename).ts"
        }
    },
    "typescript.tsdk": "./node_modules/typescript/lib",
}

I'm trying it on the line li>a[routerLinkActive="active" [routerLink]="['/applications']"]. But this error appears anytime I include [...] in my emmet snippet. If I just have a normal HTML5 tag, it works fine, but I find it annoying to have to add all my attributes in after the fact.

@jakehockey10 You seem to have nested [] and I am not sure what your expected output is

li>a[routerLinkActive="active" routerLink="/applications"]
expands to
<li><a href="" routerLinkActive="active" routerLink="/applications"></a></li>

@ramya-rao-a I did have square brackets around routerLink because it needs to have those square brackets around routerLink after the expansion. Before the last update, this was valid and upon pressing the tab key, I would get the following:

<li>
    <a href="" routerLinkActive="active" [routerLink]="/applications"></a>
</li>

But even if I don't do that for routerLink, anytime I have the outermost square brackets, I get the error message I mentioned earlier.

@jakehockey10 I'll look into the nested brackets

But you say even the outermost square brackets give you the error message. Can you try li>a[routerLinkActive="active" routerLink="/applications"] ?

Yes, that gives me the error as well :(

@jakehockey10 Let's continue this in a separate issue since this is specific to the square brackets in abbreviations (https://github.com/Microsoft/vscode/issues/32986)

This current issue has a lot of people and I don't want their notifications to be spammed

As a coder, the last month without emmet tab function is painful, I didn't realize 1.15.0 version abandoned emmet tab until I see this issue. I decided to go back to sublime because of this, though you finally fix this in new version, I still think that this kind of casual change on important functions should be avoided.

I'm not sure what happened in the latest updates, but I can't get any autocompletion on tab at all anymore. I have enabled and disabled all possible settings in userconfig.json and in keybindings. (For example, in settings.json: "editor.tabCompletion": true).

When I type div in the editor and press tab, nothing happens.
When I type < in the editor and choose a html tag from the list, and press enter, nothing happens. The tag is not even closed.

@Skura23 @KokoDoko Whenever you see a feature acting different or stopped working, please spare a few minutes in scanning through the Release Notes for that release.

Here are a few links that might interest you

@ramya-rao-a I find the release notes somewhat unclear on what setting to set to true or false to get autocompletion working again. Either way, nothing I tried so far has worked... or is this expected behavior and do we need an extension just to autocomplete a html tag?

@KokoDoko If you are looking to auto complete <div> to <div></div>, you need an extension for it in VS Code versions 1.15 and earlier. If you are on 1.16 you don't need an extension. See https://code.visualstudio.com/updates/v1_16#_html-close-tags

If you want to expand Emmet abbreviations and snippets using tab, set emmet.triggerExpansionOnTab to true. Read Docs for Emmet in VS Code for everything related to Emmet.

If the above still don't work for you , please open a new issue.
This current issue is about tab and Emmet which has already been resolved and I'd rather not spam the notifications of the many people already on this thread.

  • VS Code -v 1.16

So I have these settings:

  "emmet.triggerExpansionOnTab": true,
  "editor.wordBasedSuggestions": false,
  "emmet.showExpandedAbbreviation": "always"

What i get is this:
autocompletion-screenshot

As you can see "width: ;" is the fourth option because of the alphabetical order. Is there a way to prioritize the emmet type of autocompletions over those "key" options (intellisense options i guess)?

I wouldn't want to disable the "key" ones completely. It would be handy :).

@sebhewelt See https://code.visualstudio.com/updates/v1_16#_emmet-suggestions-as-snippets

Also note that editor.snippetSuggestions can be scoped to the languages. If you don't want to set it for all files, then

"[css]": {
        "editor.snippetSuggestions": "top"
    }

Not working here... ๐Ÿ˜ฉ
I've set

{
    "emmet.includeLanguages": {
       "javascript": "javascriptreact"
    }
}   

I've tried to expand App to <App></App> through Emmet: Expand Abbreviation from Command Pallete, nothing. Language is set to JavaScript React (Babel), file extension is .js.

Driving me crazy

@ramya-rao-a Wow!
It works, thanks!
Howeverโ€”how was I supposed to solve it by myself? Is there a way to see what language identifier I'm using in a file?

BTW, Tab extension still not working (even though it's set to true) but that's less of a problem for now

@selrond I understand this is one of the cases, where one couldnt have figured the solution out on one's own. I have logged an issue in the babel extension repo to see what can be done to get Emmet support in embedded languages out of the box. Once we get a decent solution there, I can reach out to other extensions that provides similar embedded language support.

You can use the Developer: Inspect TM Scopes command to get the language info under the cursor.

For tab still not working, can you log a separate issue and we can take it from there?

@ramya-rao-a Thanks for the Developer: Inspect TM Scopes tip, extremely helpful!

@ramya-rao-a

For tab still not working, can you log a separate issue and we can take it from there?

Here it is: #34929

Was this page helpful?
0 / 5 - 0 ratings

Related issues

trstringer picture trstringer  ยท  3Comments

lukehoban picture lukehoban  ยท  3Comments

shanalikhan picture shanalikhan  ยท  3Comments

chrisdias picture chrisdias  ยท  3Comments

philipgiuliani picture philipgiuliani  ยท  3Comments