Provide a way for a different language to receive html language features

[xorye]

Hi, it would be great if there was a way for different HTML-like languages to receive HTML language features. Templating language extensions in the VS Code Marketplace could benefit from this.

Our use case:
We are working with a new HTML templating language with its own language config and TextMate grammar and would like to have the built-in HTML language features for the language. Features like auto indent, auto close tags, auto rename tags.

In our package.json we've created a new language called "Qute", for the Qute Templating Engine, with its own language config and grammar.

I don't think doing "files.associations": {"*.(our-extension)": "html"} in settings.json would help here because changing the file association would override the Qute grammar and language config.

Maybe there could be a way to register new HTML-like languages to the HTML language server?

Or is there a better way to handle this?

Thanks!

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Uninstalling language pack for current display language does not update display language setting (#82791)
• Document guidelines to enable language features for embedded languages (#47288)

[xorye]

#55088 seems like a solution.

Please feel free to close this issue

[xorye]

Hi @aeschli, it looks like your comment in #55088 (comment) suggests forwarding requests by executing VS Code commands like vscode.executeCompletionItemProvider to get completion support, for example.

But what about html features like auto close tags and auto rename tags? The HTML LS accepts html.autoClosingTags and html.mirrorCursorOnMatchingTag requests to facilitate those features but I don't think it's possible to call specific requests to a specific LS using VS Code commands.

Would the solution here be to create our own LS that accepts autoClosingTags and mirrorCursorOnMatchingTag requests? To avoid redundancy, I think it would be ideal if I could communicate with the HTML LS instead.

Another solution would just be to add our language in this array:

vscode/extensions/html-language-features/client/src/htmlMain.ts

Line 73 in 76d0b30

let documentSelector = ['html', 'handlebars'];

but because the Qute language is new, I understand if that's not favorable in general, to have random languages in the VS Code source code.

[aeschli]

Yes, we want to make the full-html language (html + css + javascript) server more reusable
a. as a service like the current html-language-service, to be used as library by other language servers
b. as a new contrib point so html-like languages (e.g. html template languages) can provide a custom scanner and ask to be served by the html server (and get added to the array that you were pointing to). The issue for that is #49210

autoClosingTags and mirrorCursorOnMatchingTag would be made available in both approaches.

It is also planed to make autoClosingTags and mirrorCursorOnMatchingTag language features for all (using regular provider). So they would be reusable like code completions.

If you have your own language server, I'd recommend for adding html as a service (a.) so you are self contained, avoid versioning issues and are able to give context to the HTML language service (e.g.) globals) gets as well as have more control over the user experience.

Approach (b) to enable a fast adoption of a template language where there is no language server. The capabilities added will be limited to inheriting HTML support.