Allow mapping custom extensions to language IDs about ltex-ls

[valentjn]

The Language Server Protocol (LSP) has the concept of language identifiers, which are used by language servers to determine the type of documents. File extensions shouldn't be used as they are not reliable, they may be missing, and there may be clashes.

LT_EX only uses file extensions (i.e., the source code quoted in the issue description) when running commands such as LTeX: Check All Documents in Workspace, because in this case, files are checked that are not open in the language client (editor) and therefore, no language identifier is available for them. For regular checking, file extensions are not used, only language IDs.

IMO, it would be confusing UX to have a setting that somehow supplements/overrides the editor choices of language IDs. Besides, I don't really see enough possible use cases besides MDX.

A better solution is to make the language client send a distinct language ID (mdx in this case), e.g., by installing extensions that add language support for the specific language, and make the language server recognize the language ID.

Of course, most desirable would be adding full support for MDX to LT_EX. Looking at examples, MDX can be JavaScript with some Markdown in it, which would be pretty hard to parse and probably out-of-scope for LT_EX. However, it's easily possible to check MDX as Markdown, if you're fine with all the false positives.

[bencmbrook]

Appreciate the thorough response and understand your reasoning. That global override can work well enough for my use case.

Thanks—closing this out.