Is your feature request related to a problem? Please describe.
Right now, we don't allow multiple file extensions for the same DSL. Both the LSP and VS Code do not have this restriction.
LSP doesn't talk about extensions, and even discusses how a single language server could host multiple languages (it says we should use the languageId property of a document, not re-inspect the extension of the file).
VS Code allows you to configure multiple extensions for a single language, the extension property is always a list in package.json.
Apart from the disparity to LSP and VS Code, we have a customer where the same language has multiple extensions. There is a work around, but that does case quite a few more interpreters to be loaded, and other features of VS Code are negatively impacted by splitting all those extensions into different languages.
Describe the solution you'd likeregisterLanguage/Language should be changed, to provide a set[str] extension instead of a str extension Parameter. This will involve some invasive changes in rascal-lsp project, and a few small ones in rascal as well. I think we should make an overload/function constructor to support the old single extension version, that just constructs the set when needed.
Describe alternatives you've considered
Defining every different extension with a different language would involve loading parallel evaluators (increasing memory pressure and loading time quite a bit) and it also hurts other VS Code features, which are normally connected/shared to the language identifier.
Is your feature request related to a problem? Please describe. Right now, we don't allow multiple file extensions for the same DSL. Both the LSP and VS Code do not have this restriction.
LSP doesn't talk about extensions, and even discusses how a single language server could host multiple languages (it says we should use the
languageId
property of a document, not re-inspect the extension of the file).VS Code allows you to configure multiple extensions for a single language, the extension property is always a list in package.json.
Apart from the disparity to LSP and VS Code, we have a customer where the same language has multiple extensions. There is a work around, but that does case quite a few more interpreters to be loaded, and other features of VS Code are negatively impacted by splitting all those extensions into different languages.
Describe the solution you'd like
registerLanguage
/Language
should be changed, to provide aset[str] extension
instead of astr extension
Parameter. This will involve some invasive changes in rascal-lsp project, and a few small ones in rascal as well. I think we should make an overload/function constructor to support the old single extension version, that just constructs the set when needed.Describe alternatives you've considered Defining every different extension with a different language would involve loading parallel evaluators (increasing memory pressure and loading time quite a bit) and it also hurts other VS Code features, which are normally connected/shared to the language identifier.