languageId is set incorrectly?

[minimalprocedure]

I made an OCaml syntax highlighter for LiteXL, and trying to use it with the LSP server (ocaml-lsp) I realized that probably the "languageId" property (in init.lua) is set incorrectly (at least as per https://microsoft.github.io/language-server-protocol/specifications/specification-current/) to the file extension (without dot) and not to a standard identifier. Changing to:

    --languageId = Util.file_extension (doc.filename),
    languageId = server.language,

The server is working correctly (it seems) with a configuration like:

    lsp.add_server {
       name = "ocaml-lsp",
       language = "ocaml",
       file_patterns = {"%.ml$", "%.mli$"},
       command = {"ocamllsp"},
       verbose = false
    } 

[jgmdev]

All language servers I have tested work properly with the file extension and changing to use the language property by default would break clangd server which handles both C and C++ and seems to work properly with file extensions. For now I added a new property called id_not_extension so your ocaml declaration should look now like:

lsp.add_server {
  name = "ocaml-lsp",
  language = "ocaml",
  file_patterns = {"%.ml$", "%.mli$"},
  command = {"ocamllsp"},
  id_not_extension = true,
  verbose = false
} 

Also added ocaml-lsp entry as shared by you to the lsp/config.lua file with the id_not_extension property already set to true as seen on the referenced commits.

[minimalprocedure]

Some servers work with extensions due to initially unclear languageId policy (link). I think that clangd doesn't work with the extension but with the identifier: cpp or c (maybe some others). They are identifiers and incidentally extensions (I think), C++ can have various extensions (cxx, hpp, ...). Anyway, no problem, the code is yours :) and your temporary solution it's okay for me too. I'm not a specific user of liteXL and it was just to expand the OCaml possibility in various editors. Many thanks anyway. :)

m.

[jgmdev]

Clangd seemed to properly work when sending h as languageId but Im not even sure anymore :) Thanks for the diagnosis and reporting the issue. Maybe the logic can be improved by allowing a table of supported languages each paired with optional file extensions or allowing multiple declarations of same language server with different language identifiers and prevent it from getting launched more than once and instead reuse active one.

If you have suggestions please share them, will leave this issue open until better strategy is achieved (which I think could be allowing a table of supported languages).