-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emmet css abbreviation not expanded in style block in html file #28039
Comments
I created this issue, because it is not mentioned here: #27697 |
This works in css/scss/less files, but not inside the |
I initially thought that the completion provider for css from emmet does not get called here because the document has the html language mode. And so logged #28047 But interestingly, the built-in css completion provider does get called. @aeschli @jrieken How is that in the above case the built-in css completion provider is called but not the emmet css completion provider? If the css extension/language server does something special to be able to provide completion items in html file, what do you suggest other extensions who want to do the same do? |
It always depends on the language you are registering for. I'd say that inside |
@jrieken See https://github.com/Microsoft/vscode/blob/ramyar/emmet-fixes/extensions/emmet/src/extension.ts#L54 I have 2 separate completion providers for html vs css should we specify anything else in the DocumentSelector for VS code to use the registered completion provider for embedded languages? |
Hm, that looks correct... Would require some debugging in |
@jrieken Yes. The changes are in master, so you can try this locally. |
Funky.. If I press Also, when I invoke suggestions inside an empty rule (remove
|
Yes, that is from emmet. If you expand the docs you will see the preview for the expansion. In your case above, the completion item is coming from the html completion provider in emmet i.e for
The first one must be coming from the html extension.
I dont see that in Insiders but I see that in the locally built VS Code. Weird.. how is that? We dont surface errors from extensions in a non dev env? |
Ok, now I know what's up. @aeschli Will have all the detail but I remember correctly nested languages aren't surfaced like that. While we have a scope |
😭 |
And of course, we don't expose the scope to extensions. You know this is like the 4th time I get to this crossroads of needing scopes in extensions 😢 @aeschli Any plans to expose the nested language info to extensions? Or suggestions to extensions on any workaround? |
Interrupt: Why did you decided to split off and make emmet an internal extension? |
I think @aeschli has a re-usable html parser (on npm) that you could use to figure out if you are in css or not. And then that info will be reliable, not based tokens (see attached screen shot, the css-scope only starts on the next line) |
@ramya-rao-a internal vs. external, when you have so many problems, why did you decided to switch so fast, even when there are no apis available? |
@jens1o Well I'd say not fast enough :) The 2 issues with current emmet integration in VS Code as described here: https://code.visualstudio.com/updates/v1_13#_emmet-abbreviation-expansion-in-suggestion-list are the main reasons to move to the newer model of using the suggestion list for emmet. Over the past year we have had many users face this issue and moving to the suggestion model was the right move.
Emmet has been a feature shipped with VS Code since the beginning. Making it an external extension would require users to install it explicitly. Therefore, the decision for internal vs external.
Emmet features are not core to an editor per say. These are add-ons. And so make sense more as an extension. Initially, the way emmet library worked, it was not possible to have it as an extension for VS Code. For Atom, say it was possible because it has a different extensibility model, it is hackable at every level. Now, that @sergeche has modularized the core logic of emmet, we can now have emmet expansion coming from completion providers and rest of the emmet features from an extension.
Unlike @sergeche or many power users of emmet I don't have the luxury of knowing emmet and all its scenarios in and out. Because I don't use emmet at all in my job. That's why I depend on amazing people like you to dogfood the initial implementation and come up with the corner cases where the feature doesn't work. Thanks to the open source model of things, we can do that :) i.e work together to hash out scenarios As @sergeche suggested here: #27628 (comment), we can still parse the file in an efficient way to get the info we need to solve both this and the linked issue. So even if scope info or the nested language info is not available as apis, we can still do this. Worst case scenario, I can easily move the new emmet from the internal extension to VS Code core and make use of the scope info available there. Either way, by the end of the June milestone, we are going to have a great emmet experience |
Wow, thanks for the detailed answer. I'll continue to work with it(and report odd things), to help you. 😋 |
The fix will be out in the Tuesday's Insiders |
@ramya-rao-a You only changed the Completion Provider, but not the actions (at least expandAbbreviation action)? And another problem: You implementation will provide emmet in the start tag of a <style |> I'm working on a tool for my team with monaco-editor and trying to backport the new emmet vscode extension to monaco (Now the Completion Provider and expandAbbreviation action just work). I had never used emmet before neither, but now I think the implementation will be very complex: you need to handle normal HTML, in |
@ramya-rao-a you have to check if cursor is not inside |
@CnSimonChan I had another task in mind to consolidate the code between the completion provider and the action which I was planning to do today which would cover your concern. And good catch on the @sergeche For now I am using https://github.com/Microsoft/vscode/blob/master/extensions/emmet/src/emmetCompletionProvider.ts#L134 for validating the position. I'll take another look at the atom implementation to ensure I have not missed any other cases. |
@CnSimonChan With 8902a30 you now have the same validations being run and syntax being used by the completion provider and the expand abbreviation action.
You bring up another good point about the style attribute. Logged #29066 for the same. Yes, things are getting complex in this model where a lot of work has moved from emmet to editor. |
@ramya-rao-a It works very well now, maybe another improvement will be re-parse the content of For monaco, I wrote a minimal compatibility layer to bridge monaco's I have two more question with this extension:
|
I gave this a thought, but will not be doing this for the current iteration. Logged #29113 and added a help-wanted label on it.
Not sure about this. The shrink-wrap is used during shipping time, so not needed during the development phase. Did you try with a lower npm version?
Ahhh... This is something I have been needing as well. @sergeche Could you help here ? |
No, I have only 5.
I have |
Note to verifier:
|
Steps to Reproduce:
(you can use any css property, this was my first, real-world, live example)
d:b
display: block;
d:b
and hitTab
/Enter
/...The text was updated successfully, but these errors were encountered: