Steps to Reproduce:
"editor.tabCompletion": false in settings.jsond-b in css and press Tab for Emmet abbreviation expansion, you'll get something like -ms-word-break: instead of display: block (surprise!).Expected:
"editor.tabCompletion" = false tab shouldn't expand the suggestions"editor.tabCompletion" = true tab should expand using the first suggestionIt's said "editor.tabCompletion" works better when "editor.quickSuggestions" is false. But if I switch it off, I get no suggestions at all. I need them and I actually use them often when abbreviations aren't suitable.
This is actually a horrible behavior, since it makes me chill when I try to use Emmet inside the VSCode.
Video: http://take.ms/KgTwR
Just a tip for those who will work on this issue: it is not related to Emmet :smile_cat:
tldr; this is a configuration challenge
Let me start by naming the individual pieced that are involved here
tab)tab or entertab)From your description I understand that you have suggestions shown as you type and that pressing tab unexpectedly inserts those. Instead you want emmet to _win_ - despite the suggest list showing.
Good news is that all of this behaviour is configurable using the keybindings.json file - for instance you could rebind insert suggestion to enter or boost the priority of emmet to always win.
@jrieken thanks for your comment.
I don't won't to rebind a key for inserting suggestions. I've always used tab for this, in every editor I've used before (Atom, Sublime and others). Changing keybinding is a messy solution for me (it also forces me to port it onto every workstation I use). I just want a default configuration options work the way they're described in the docs.
Current issue isn't about chaining keybindings, it's about buggy options. The actual challenge here is to make configuration work without issues.
@alexandrudima and @Tyriar, your comments are appreciated.
Just to clarify - you prefer a default in which tab always run emmet regardless the suggestion popup showing or not?
I can confirm that tabCompletionoption doesn't work.
"editor.tabCompletion": false,
"editor.quickSuggestions": true
Suggestions still expand on tab key, while I except them to expand on enter when tabCompletion is false.
@naxsooley I guess my explanation in https://github.com/Microsoft/vscode/issues/13141#issuecomment-252186346 was not clear. tabCompletion is a different feature then suggest, that tabCompletion: false has no effect on the suggestion feature
@jrieken ahh, I've misunderstood the tabCompletion option.
So we have the acceptSuggestionOnEnter option:
// Controls if suggestions should be accepted 'Enter' - in addition to 'Tab'. Helps to avoid ambiguity between inserting new lines or accepting suggestions.
"editor.acceptSuggestionOnEnter": true,
I suggest you to add a same option for Tab key. We should finally achieve:
// Controls if suggestions should be accepted 'Tab'. Set false to avoid snippets dubbing.
"editor.acceptSuggestionOnTab": false, // should be true to keep current default behavior
// Controls if suggestions should be accepted 'Enter'. Helps to avoid ambiguity between inserting new lines or accepting suggestions.
"editor.acceptSuggestionOnEnter": true,
We may use Enter for suggestions then and Tab for snippets.
Arguably since there is full control over the keybindings. Even the "editor.acceptSuggestionOnEnter": true-setting (which I added 馃檲 ) is already questionable because you can achieve the same using keybinding-customization. I'll keep my ears open, if more people find this annoying we can add a setting - folks are usually more relaxed changing settings over keybindings. Thanks
@jrieken +1 goes to you for adding this option :smile: Settings are much better than keybindings, those are hacky due syntax and should be duplicated into multiple files for each platform (mac, pc, nix). Current settings backuper via gist doesn't support multi platforms right now - no way to easily transfer keybindings, acceptSuggestionOnTab would trick that.
@jrieken I've to clarify my answer.
Keybindings aren't suitable, because they may differ on multiple platforms. You can not mix mac and windows keybindings, so then, we need an acceptSuggestionOnTab option.
You can not mix mac and windows keybindings
We should fix that - internally differentiate them,we just don't surface them that way. I am sure @alexandrudima has an issue for that
You can not mix mac and windows keybindings
@jrieken that task would be hacky, because of the complexity. I'm agree with @naxsooley and find it much easier to just add an extra option.
@jrieken, @alexandrudima, @Tyriar, any progress on this issue? Current issue is closed, but not fixed.
As promised I am keeping my ears open but so far there are no other questions/requests in this direction. Adding a configuration option is more expensive then it seems because it needs to be maintained and dragged along.
Apart of keybinding customisations, there is the "editor.quickSuggestions": false-option that allows you to turn of 24x7 IntelliSense, enabling the Emmet-first scenario in yet another way.
@jrieken open current issue back please, I'd like to know when it gets closed.
Most helpful comment
Arguably since there is full control over the keybindings. Even the
"editor.acceptSuggestionOnEnter": true-setting (which I added 馃檲 ) is already questionable because you can achieve the same using keybinding-customization. I'll keep my ears open, if more people find this annoying we can add a setting - folks are usually more relaxed changing settings over keybindings. Thanks