HTML `matchCLosingTags`: Configure language when loading with language-data pack

v6
1

Are there any ways to configure a language extension when it’s being loaded using the language-data pack?

Looking at language-data/language-data.ts at main · codemirror/language-data · GitHub it doesn’t look like the load() function for the languages pass through configuration.

Ultimately, I’m looking to enable/disable matchClosingTags and autoCloseTags for HTML. Those are enabled by default, but I’d like users to be able to disable that if they want.

2

No, the language description objects in that package provide just the default configuration. But you can add additional custom language descriptions to the start of the array of desrciptions that you actually use to override some, if you need to.

3

Thanks for the response.

Is html the only one in language-data that implements matchClosingTags⁠ and autoCloseTags⁠ via config?

4

A nice enhancement would be to allow the load functions in language-data to pass in config options:

  LanguageDescription.of({
    name: "HTML",
    alias: ["xhtml"],
    extensions: ["html", "htm", "handlebars", "hbs"],
    load(config) {
      return import("@codemirror/lang-html").then(m => m.html(config))
    }
  }),

Possibly merging objects when necessary:

  LanguageDescription.of({
    name: "JSX",
    extensions: ["jsx"],
    load(config) {
      return import("@codemirror/lang-javascript").then(m => m.javascript({ ...config, jsx: true }))
    }
  }),
5

Following back up on this: It would be really great if you could configure languages from the @codemirror/language-data pack. Right now I’m having to add extra logic to detect languages or even override the load function to just provide matchBrackets and other basic config options.

Another possibility would be to have a configuration facet instead of the config being in the extension function, so those values could be added or extended separate from the actual language initialization.

6

The idea of adding a parameter to load is really not viable—the type would be different for every mode, and, more importantly, this is a cached thing per LanguageDescription object, and being able to pass in configuration data would break the assumption that this is a single, reusable value.

So, again, the idea is to create your own LanguageDescription objects if you want to change the language’s configuration, possibly by reusing fields from the ones in language-data and adding a custom load function.