Test: Enable emmet for other languages #9500

[egamma]

Test for #9500

• Windows and Mac @ramya-rao-a, @waderyan
• Any OS @aeschli

Complexity 1

You can enable emmet for other languages both as a user and as a language contributor.

Enable emmet for a new language as a user.

As a user you can define an emmet syntax profile and associate an emmet supported profile to a language. For a list of supported emmet profiles see #9500 (comment). For example to associate java with the html syntax profile you can define the setting:

{
  "emmet.syntaxProfiles": {
    "java": "html"
  }
}

• Verify that emmet abbreviations are expanded inside an java file using the html profile.

Enable emmet as a language provider

As a language provider you can associate your language with an emmet syntax profile by adding an emmet supported profile in the scope name of the grammar (textmate language grammar). For example, define the scope of you

        "grammars": [
            {
                "language": "foo",
                "scopeName": "text.html.foo"
            }
        ]

Define a language foo as shown above.

• Verify that in file of type foo you emmet abbreviations using the html support.
• Verify that you get emmet abbreviations independent of where html appears in the scope name.

[waderyan]

@egamma

Verify that emmet abbreviations are expanded inside an html file using the html profile.

Do you mean "inside a Java file using the html profile"?

If not I could use some clarification on how to test part one.

If you did mean Java, these are the steps I took.

Add the following to settings.json

    "emmet.syntaxProfiles": {
        "java": "html"
    }

Create test.java. Type ! and tab to see emmet html output.

[waderyan]

For reference this is what I put in the extension's package.json

"contributes": {
        "languages": [
            {
                "id": "foo",
                "extensions": [".foo"]
            }
        ],
        "grammars": [
            {
                "language": "foo",
                "scopeName": "text.foo.html",
                "path": "grammar.tmLanguage"
            }
        ]
    },

And here is my sample grammar.

{  
    scopeName = 'source.untitled';

    fileTypes = ( );
    foldingStartMarker = '\{\s*$';
    foldingStopMarker = '^\s*\}';
    patterns = (
        {  name = 'keyword.control.untitled';
            match = '\b(if|while|for|return)\b';
        },
        {  
            name = 'string.quoted.double.untitled';
            begin = '"';
            end = '"';
            patterns = ( 
            {  
                name = 'constant.character.escape.untitled';
                match = '\\.';         
            }
        );
        },
        );
}

[mrmlnc]

@waderyan,

Create test.java. Type ! and tab to see emmet html output.

Yes, you're right.

Correct result:

scopeName": "text.foo.html",

For correct results, you should use "text.html.foo".

P.S.: for testing you can use any extension that provides the HTML syntax (or any language from #9500 (comment)). For example: https://github.com/mrmlnc/vscode-vash.

Correct result:

[dbaeumer]

@aeschli @ramya-rao-a friendly reminder to test this item.

[aeschli]

Naming my grammar's scope in a specific way so that I get emmet proposals seems like hacky solution to me. It only is feasible when my language is a subset of that language, given that the scope name also has an impact on colorization (at least as long as we flatten our scopes).
A more explicit solution would be better.

[ramya-rao-a]

@egamma

Verify that you get emmet abbreviations independent of where html appears in the scope name

The newly defined language only gets emmet abbreviations if the scope name was text.html.foo. They do not work when html is moved around in the scopename. Which makes sense because scopename is supposed to have hierarchically defined languages from left to right

scopeName (line 1) — this should be a unique name for the grammar, following the convention of being a dot-separated name where each new (left-most) part specializes the name. Normally it would be a two-part name where the first is either text or source and the second is the name of the language or document type. But if you are specializing an existing type, you probably want to derive the name from the type you are specializing. For example Markdown is text.html.markdown and Ruby on Rails (rhtml files) is text.html.rails. The advantage of deriving it from (in this case) text.html is that everything which works in the text.html scope will also work in the text.html.«something» scope (but with a lower precedence than something specifically targeting text.html.«something»).

From: https://manual.macromates.com/en/language_grammars

[ramya-rao-a]

@egamma @mrmlnc Any thoughts on @aeschli's comment above?

[mrmlnc]

@ramya-rao-a, @aeschli, I think that it's not hacky solution. If the language inherits syntax of another language, the developer needs to specify him in scopeName. Now we have implemented the following mechanism:

• If language is excluded by emmet.excludedLanguages, then Emmet does not work.
• If language included in ['html', 'xhtml', 'css', 'xml', 'xsl', 'haml', 'jade', 'jsx', 'slim', 'scss', 'sass', 'less', 'stylus', 'styl'], then Emmet works. This is list of all languages that supported by Emmet.
• If the language is not listed above, we get his parent language. And so for each parent language.

In any case we get result.

For example:

• text.html - supported by html
• text.jade - supported by jade
• source.css.less - supported by less
• text.html.nunjucks - supported by html
• text.html.handlebars - supported by html
• source.js - not supported
• source.c.platform - not supported
• text.xml.xsl - supported by xsl
• text.xml - supported by xml
• text.html.markdown - supported by html
• text.html.rails - supported by html

In the case of an explicit solution, for example, option in package.json file, we do what has already been done for us. Almost the same algorithm used in the Emmet for Atom, Sublime, Brackets and Text Mate 2.

In the current solution does not suit me only this rule (syntax !== thisLanguage in editorAccessor.ts#L176), becase I do not understand why it needed here and this restricts the language support (hello, MIME: #11329 (comment)).

P.S.: Maybe I'm wrong.