Support custom snippets in new Emmet

With ac60143 the snippets.json file from emmet.extensionsPath is now read and used by new emmet

But since the new emmet modules do not use old style snippets, only the variables section of the snippets.json file is used.

This issue is to track the possibility of having custom snippets in the new emmet as well

VS Code version	OS
1.14.0	Win 10 x64 pro (french) 14393

Yes with v1.14.0, there is improvements but as you said, our custom emmet snippets are not honored with "emmet.useNewEmmet": true, only variables are loaded.

Example:

	"css": {
		"snippets": {
			"!": "!important;",
			"bxsh:h": "box-shadow:${1:inset }${2:hoff} ${3:voff} ${4:blur} ${5:spread }hsl(${6:0}, ${7:100}%, ${8:50}%);",
			"bxsh:ha": "box-shadow:${1:inset }${2:h} ${3:v} ${4:blur} ${5:spread }hsla(${6:0}, ${7:100}%, ${8:50}%, ${9:1});",
			"c:h": "color:hsl(${1:0}, ${2:100}%, ${3:50}%);",
			"c:ha": "color:hsla(${1:0}, ${2:100}%, ${3:50}%, ${4:1});",
			"tsh:h": "text-shadow:${1:h} ${2:v} ${3:blur} hsl(${4:0}, ${5:100}%, ${6:50}%);"
         }
     }

One can not use c:h then tab key to expand our custom expansion that are ignored. It is the same for some old default one that are still not implemented in the new emmet module such as

"c:r": "color:rgb(${1:0}, ${2:0}, ${3:0});",
"c:ra": "color:rgba(${1:0}, ${2:0}, ${3:0}, .${4:5});"

But we can still use Code built-in snippets feature for that 😉 Maybe it's time to convert my emmet snippets to the built-in one.

Sergey Chikuyonok (@sergeche)

Maybe it's time to convert my emmet snippets to the built-in one.

Yes please.

There is no good way to do this in the new emmet model until Sergey Chikuyonok (@sergeche) comes up with a plan on how he wants to do this.

So chances are we are going to ask our users to use vscode custom snippets instead of the emmet custom snippets

Old CSS snippets are mostly the same as new ones: https://github.com/emmetio/snippets/blob/master/css.json Except that : is not allowed in snippet name since it’s used to explicilty separate property name and value and use value part for further completions. I guess you can safely load css.snippets config as snippets for new Emmet but remove : from names

@ramya-rao-a

The limitations I see with vscode custom snippets are: how can we share a common snippets file across multiple language instead of duplicating snippets for each one? (php, html, etc.) Am I clear about this issue?

Fremea

Fremea I believe there is an open issue for that
Sergey Chikuyonok (@sergeche) I'll give that a try

Fremea

Done!

It needed a little work as in we can't simply pass the snippets json directly as we did before.

Fremea You will have to update the abbreviation for your snippets in the following way

no : in the abbreviation like Sergey Chikuyonok (@sergeche) mentioned above
the abbreviation should fuzzy match with the expanded value. As in you cannot have {"xyz": "margin"} This will work when you explicitly use Emmet: Expand Abbreviation but in the autocompletion it will get filtered out as there is no x or y or z in margin

@sergeche When expand takes in the options, the snippet registry being passed is just for current syntax.

Say user has configured snippets for css. The editor creates a registry for "css" with these snippets and passes to expand when user is in a css file.
Now if the user goes to a scss file, they would expect their css snippets here as well.

For this to work, editor needs to maintain the inheritance hierarchy.

Anyway, we can have this logic in the expand-abbreviation module?

Basically, both css and scss are stylesheet snippets so they can and should be used together. The reason why I’m moving away from per syntax snippets to essentially two contexts (markup and stylesheet) is that in most cases users don’t understand how they should be used. Since every editor provides different means of detecting syntax, users add something like php and hope that these snippets would work. While actually they should map syntax scope like text.html source.php to php somewhere in plugin code to make it works.

Instead, I’m moving all syntax detection logic away from Emmet into editor plugin implementation but provide easy way to use different snippet sets. For example, in VS Code you can use scope-based snippet definitions like

"source.css": { "foo": "bar" },
"source.css.scss": { "bam": "baz" }

Then you can collect all matching snippet sets for current scope and simply Object.assign(...) them to create a final abbreviation set which then you pass into expand abbreviation function

Verified in master, will confirm with the next build.

#29146 (comment) is fixed with
microsoft/vscode-emmet-helper@4394c04

@ramya-rao-a said:

@freMea Can you try your snippets (after removing the : and ensuring that the key can fuzzy match with the snippet) now?

Your css ones will work in css files in current Insiders
They will work in scss or less files in the next Insiders (20th July, 2017)

Here is a sample emmet snippets file, using last insider (08-03) :

{
	"variables": {
		"charset": "UTF-8",
		"indentation": "\t",
		"lang": "fr",
		"locale": "fr-FR",
		"newline": "\n"
	},
	"css": {
		"filters": "css",
		"profile": "css",
		"snippets": {
			"!": "!important;",
			"bxshh": "box-shadow:${1:inset }${2:hoff} ${3:voff} ${4:blur} ${5:spread }hsl(${6:0}, ${7:100}%, ${8:50}%);",
			"ch": "color:hsl(${1:0}, ${2:100}%, ${3:50}%);",
			"comsec": "/*=============================================${newline}= @${1:SectionCommentBlock} =${newline}=============================================*/${newline}${newline}${newline}/*===== End of ${1:SectionCommentBlock} =====*/",
			"comsub": "/* ---- @@${1:SubSectionComment} ---- */"
		}
	}
}

The funny thing is it works for some, doesn't for others, and add trailing ; for most.

! works as expected.
bxshh and ch works but an extra trailing ; is added (visible in the suggestion box too). The workaround is to edit the snippet to remove the existing ending ;. But you don't have to do it for the ! snippet. Hence it is inconsistent.

comsec and comsub don't work at all. But it is not very important since we can use the code built-in snippets engine for that (if only it could work on all stylesheet flavors, see below).

Emmet snippets that work in CSS work in Less or Sass, as you said. But user CSS snippets using the built-in Code engine don't. Is there a way to map a syntax snippets to other file type? (#13182 ?)

Fremea

Fremea

bxshh and ch works but an extra trailing ; but not !

I believe what Sergey Chikuyonok (@sergeche) was going for here is that if your snippet is of the form property: property value then you don't need to add the ending ;. Emmet will do it for you. Your snippet for ! was not of that form, so was used as is.

Logged #32013 for that.

comsec and comsub don't work at all

They do work if you explicitly run the Emmet: Expand Abbreviation command. For css suggestions from emmet what we have done is that we use the expanded value as the filter text. Since comsub doesn't fuzzy match with the expanded value, it gets filtered out. Rename it to say subseccom, and you will see the suggestion.

I have my work cut out documenting all of this ...

Ramya Rao (@ramya-rao-a)

Ramya Rao (@ramya-rao-a) thanks for the enlightenment.

Fremea

Fremea

thanks for the enlightenment

I am finding it hard to decipher if that was sarcasm or genuine.... :)

bxshh and ch works but an extra trailing ;

I spent some time thinking about the extra ; in the end.

I initially thought that I could strip out the extra ; in the end so that existing snippets can continue to work as is.

But now, I am leaning towards not doing that and have users update their snippets to not include the ; at the end.

Reason:

Custom snippets defined for css get used for scss, sass and other flavors of stylesheets.
sass for example doesn't need the trailing ;

Therefore, having the custom snippets not include the trailing ; is a good design.
This way emmet gets to decide whether to have a trailing ; in the end based on the file type/syntax

Makes sense?

Ramya Rao (@ramya-rao-a)

Ramya Rao (@ramya-rao-a)

Yes it makes sense. No sarcasm at all. You provided me info on undocumented points that I could not guess if they were by designed or not. You made clear what is was not.

I'm always genuine. If I find my words ambiguous before posting, I rephrase or add emoticon.

Fremea

Fremea thanks for clarifying :) I must have had my cynical hat on. Hence the confusion.
I am working on the documentation at the moment. Will have it ready early next week and will update this thread with the link

Emmet: Support custom snippets Fixes microsoft#29146

Fix emmet custom snippets for html Fixes microsoft#29146

Navigation Menu

Repository navigation

Support custom snippets in new Emmet #29146

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support custom snippets in new Emmet #29146

Description

Activity

Fred-Vatin commented on Jul 12, 2017

ramya-rao-a commented on Jul 12, 2017

sergeche commented on Jul 12, 2017

Fred-Vatin commented on Jul 12, 2017

ramya-rao-a commented on Jul 12, 2017

ramya-rao-a commented on Jul 19, 2017

ramya-rao-a commented on Jul 19, 2017

sergeche commented on Jul 19, 2017

8 remaining items

chrmarti commented on Aug 2, 2017

ramya-rao-a commented on Aug 2, 2017

Fred-Vatin commented on Aug 4, 2017

ramya-rao-a commented on Aug 4, 2017

Fred-Vatin commented on Aug 4, 2017

ramya-rao-a commented on Aug 6, 2017

Fred-Vatin commented on Aug 6, 2017

ramya-rao-a commented on Aug 6, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions