codemirror6-plugin

codemirror6-plugin copied to clipboard

Are there any ways to ensure Emmet is active for CodeMirror 6 legacy modes, such as Sass, Scss and LESS? Based on my reading of the source, it seems like the language has to be cssLanguage or htmlLanguage.

Related: Per #10, you recommended manually adding/removing Emmet based on if the language is supported, but as I look at all the Emmet source, it seems like you have a lot of code around if the syntax is supported ( such as https://github.com/emmetio/codemirror6-plugin/blob/1689794e6d8d41252fe58f15987fc349dba03bf9/src/lib/syntax.ts#L124 ). Do you think it might be possible to add a checker in the abbreviationTracker, expandAbbreviation and other extensions to ensure the extensions can run in the current document?

Unfortunately, I didn’t found a way properly detect a name of current syntax from document. So far I’, detecting syntax by checking language facet, which requires module import: https://github.com/emmetio/codemirror6-plugin/blob/main/src/lib/syntax.ts#L86-L96

Thus, it will require to import all lang modules just to detect current syntax

Tried to figure out a better approach but I haven't found anything yet. Posted on CodeMirror's forum here: https://discuss.codemirror.net/t/detect-language/5038

Finally got around to implementing snippets with the emmetConfig facet. Worked like a charm.

What do you think about using that same emmetConfig facet to specify which language / snippet type should be active?

emmetConfig.of({
  language: 'html',
  config: {
      markup: {
          snippets: {
              'foo': 'ul.foo>li.bar+li.baz'
          }
      }
  }
});

...then in https://github.com/emmetio/codemirror6-plugin/blob/main/src/lib/syntax.ts#L86 something like this:

export function docSyntax(state: EditorState): string {
    // Check user configuration first.
    const config = state.facet(emmetConfig);
    if ( config.language ) return config.language;

    // Fallback to standard language detection
    const topLang = state.facet(language);
    if (topLang === cssLanguage) {
        return 'css';
    }

    if (topLang === htmlLanguage) {
        return 'html';
    }
    return '';
}

Well, I guess it may work :) However, my only concern here is that there’s a hard dependency for cssLanguage and htmlLanguage. Also, it may not solve the issue with post-processors like Slim, Pug, SCSS etc.

What do you mean about the hard dependency? In that those languages have to be imported as a dependency and will affect the bundle size?

Considering Pug and SCSS accept plain ol' HTML & CSS, those can be allowlisted in my code based on my own language changer setup.

Yes, these languages should be imported somehow into bundle. Might lead to extra size if you have your own syntax highlighter.

Alternatively, I can remove these language bindings and leave a property, as you suggested. I think it’s OK for plugin consumers to manually set language that must be used

Alternatively, I can remove these language bindings and leave a property, as you suggested. I think it’s OK for plugin consumers to manually set language that must be used

Yes, I would be supportive of that. I do think the plug-in still relies on the HTMLLanguage and CSSLanguage in other parts, but I may be mistaken.

The plug-in should probably export a list of the languages it supports so that I could import that and use the right value for Emmet (e.g. 'sass' versus 'Sass')

import { emmetConfig, emmetSupportedLanguages } from '@emmetio/codemirror6-plugin';
emmetConfig.of({
  language: emmetSupportedLanguages.html,
  config: {
      markup: {
          snippets: {
              'foo': 'ul.foo>li.bar+li.baz'
          }
      }
  }
});

I think it’s OK for plugin consumers to manually set language that must be used

👍

Any thoughts on a manual language config option?

Thanks for pinging me up. Just published v0.3.0 which includes syntax option to specify document syntax (updated README as well).

It also includes most recent Emmet version which also supports attribute override options.

Excellent to hear! Looking forward to trying it.

By the way: It looks like you've published 0.3.0 to NPM but it isn't up here on GitHub yet.

Yeah, forgot to push it :) should be available already

Thanks. Awesome work, @sergeche. Looking forward to trying that out in our setup.

We're able to do all of this properly with the syntax config property. I think this issue is all resolved now, gonna close it out but feel free to reopen if there was still something you want to do here.