Feature Request: Enable emmet for other file extensions.

[jixunmoe]

• VSCode Version: 1.3.1
• OS Version: Ubuntu 16.06

Steps to Reproduce:

1. Install Nunjucks plugin.
2. Type p and press tab.
3. \t was inserted.

Expected Result:

1. p expanded to <p></p>.

I was looking for the setting to enable emmet, but it seems hard-coded in the source (src/vs/workbench/parts/emmet/node/editorAccessor.ts#L20).

Can we modify this value through preference?

Thanks.

[fahrradflucht]

I think thats an issue that comes up not the first time (#4962 or #4700 for example) but was always phrased as "support emmet in filetype x". I think implementing an option to turn emmet on for filetypes or if some people want it everywhere (thats how I have it in vim) would be nice and could solve this one and for all.

This option should be triggerable by plugins implementing new filetypes as well. Otherwise it would not be possible to fix issues like https://github.com/mat-mcloughlin/vscode-elixir/issues/11 since you can't just associate .eex with html or would it?

[jixunmoe]

I did an ugly hack to force it enable:

# sed -i.bak 's/emmetSupportedModes=\["html",/emmetSupportedModes=\["nunjucks","html",/' /usr/share/code/resources/app/out/vs/workbench/workbench.main.js

Everything seems fine for now.

[egamma]

@mrmlnc what would be a good way to expose this that is consistent with emmet. Now that VS Code exposes emmet preferences and profiles?

[mrmlnc]

@egamma, now it is difficult to say something.

The main problem is that we have a list of language identifiers that cannot be edited and supplemented. This imposes on us the responsibility to resolve issues such as this.

Now our main problem is the isEmmetEnabledMode function.

I see several ways to solve this problem.

Very simple way

Expand the list of language identifiers use emmet.syntaxProfiles property. For example:

Editor settings

{
  "emmet.syntaxProfiles": {
    // force HTML profile for Nunjucks syntax
    "nunjucks": "html"
  }
}

getSyntax function

// Supported by Emmet languages
const baseEmmetLanguages = ['html', 'css', 'xml', 'svg', 'xsl', 'haml', 'jade', 'jsx', 'slim', 'scss', 'sass', 'less', 'stylus', 'styl'];

public getSyntax(): string {
  let position = this.editor.getSelection().getStartPosition();
  let modeId = this.editor.getModel().getModeIdAtPosition(position.lineNumber, position.column);
  let syntax = modeId.split('.').pop();

  // Pseudo code
  let syntaxProfilesLanguages = editor.settings.emmet.syntaxProfiles;

  if (syntaxProfilesLanguages[syntax] && typeof syntaxProfilesLanguages[syntax] === 'string') {
    return syntaxProfilesLanguages[syntax];
  }

  // Default checks for `typescriptreact`, `sass-indented` and other IDs
  // ...

  return syntax;
}

Pros

• We don't need to do anything.
• Looks decent.

Cons

• Full responsibility rests with the end user, not the creator of the plugin.
• Removed settings - write again.
• We still need to have conditions for certain syntaxes. (typescriptreact, sass-indented and etc).

Best way

This method solves the problem fundamentally.

Each language has a chain of heritage in tmLanguage or language.json. Also the scope is specified in the package.json file in each language extension (contributes.grammars.scopeName). This parameter is stored in the scopeName field.

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»).

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

For example, this method is used in Atom. Thus we can 100% be sure that Emmet works for all languages, that he can support.

Warning

Unfortunately, some languages do not have this field. See code example below (razor).

For example with pesudo code:

// Supported by Emmet languages
const baseEmmetLanguages = ['html', 'css', 'xml', 'svg', 'xsl', 'haml', 'jade', 'jsx', 'slim', 'scss', 'sass', 'less', 'stylus', 'styl'];

public isEmmetEnabledMode(): boolean {
  let syntax = this.getSyntax();
  return Boolean(syntax);
}

public getSyntax(): string {
  // Pseudo code
  let scopeName = getDocumentSyntaxScopeName();

  // scope[0] -> source or text
  // scope[1] -> parent syntax
  // ...
  // scope[n] -> current syntax
  let scopes = scopeName.split('.')

  // For example:
  //
  // [1] Less -> source.css.less
  // [2] CSS -> source.css
  // [3] Java -> source.java
  // [4] PHP -> text.html.php
  // [5] ASP vb.NET -> source.asp.vb.net

  let currentSyntax = scopes[scopes.length];
  // [1] Less -> source.css.less -> less -> true -> return `less`
  // [2] CSS -> source.css -> css -> true -> return `css`
  // [3] Java -> source.java -> java -> false
  // [4] PHP -> text.html.php -> php -> false
  // [5] ASP vb.NET -> source.asp.vb.net -> net -> false
  if (baseEmmetLanguages.indexOf(currentSyntax) !== -1) {
    return currentSyntax;
  }

  let parentSyntax = scopes[1];
  // [3] Java -> source.java -> java -> false
  // [4] PHP -> text.html.php -> html -> true -> return `html`
  // [5] ASP vb.NET -> source.asp.vb.net -> asp -> false
  if (baseEmmetLanguages.indexOf(parentSyntax) !== -1) {
    return parentSyntax;
  }

  // Default checks for `typescriptreact`, `sass-indented` and other IDs
  //
  // Handlebars (hbs), erb, ejs, twig with extension?
  if (/\b(razor)\b/.test(syntax)) { // treat like html
    return 'html';
  }

  if (/\b(typescriptreact|javascriptreact)\b/.test(syntax)) { // treat like tsx like jsx
    return 'jsx';
  }

  if (syntax === 'sass-indented') { // map sass-indented to sass
    return 'sass';
  }

  // [3] Java -> source.java -> return null -> drop Emmet
  // [5] ASP vb.NET -> source.asp.vb.net -> return null -> drop Emmet
  return ''; // may be null or false ?
}

Pros

• All languages automatically have support Emmet.
• The end user must not do anything except install the extension.

Cons

• A lot of code.
• We still need to have conditions for certain syntaxes. (typescriptreact, sass-indented and etc).

Not a problem, but need to optimize language checking. In the above code checks only the current and parent syntax. But in the real case, a set of syntaxes can be unlimited (see ASP vb.NET source.asp.vb.net).

For example, Atom, checks first only the current and parent syntax and, if not, then begins to check the entire chain: https://github.com/emmetio/emmet-atom/blob/master/lib/editor-proxy.coffee#L207-L223

[egamma]

@mrmlnc great analysis thanks. What is obvious is now that we support the syntaxProfiles setting the hard coded behaviour in isEmmetEnabledMode function must be removed.

I've added this on the plan for August since we are just wrapping up the July update.

[egamma]

@mrmlnc starting to implement this. I think we need both solutions that you described above:

1. we should honor when the user defines a different profile for an existing language
2. it should be possible to contribute a language to vscode that gets emmet support without that the user needs to configure emmet support in the settings.

[mrmlnc]

@egamma, on one hand I have nothing against current solution (partial fix). But on the other hand, when I install extension (for example, HAML), I want to support Emmet out of the box. Also users must now have additional settings. And we still have a list of available languages.

And to make matters worse, users should be aware of the existing profiles Emmet, that are not described in the documentation.