Lsp-mode: multiple language mode conflict

[mistkafka]

when two language has the same :rootUri, the later bootstrap one will break. Such as：

the project construct like this:

.
├── __init__.py
├── a-python-file.py
├── a-typescript-file.ts
├── package.json
└── setup.py

This project use two language: python and typescript, and they all think the root path is the :rootUri(detail see lsp-python-mode and lsp-javascript-mode).

Now, when you only open the a-python-file.py, that's ok. But if you open the a-typescript-file.ts, the lsp-mode will think that's a python file also, so there will be so many errors..... like this:

[MaskRay]

lsp-methods.el

;; A ‘lsp--workspace’ object represents exactly one language server process.
(cl-defstruct lsp--workspace
;;;;;;;  (root nil :ready-only t)

  ;; ‘client’ is the ‘lsp--client’ object associated with this workspace.
  (client nil :read-only t)

lsp--workspace-client specifies just one client.

We can make an assumption here that only one language server will be used for a specified workspace and a specified major-mode, and use :rootUri,major-mode to choose the appropriate client in textDocument/didOpen.

Language servers may be able to handle buffers of other major-mode, e.g. .def .inc .inl are sometimes used for files to be #included in C/C++. Opening themselves may not set the correct major-mode. There should be some preferred client mechanism.

[vibhavp]

I don't think they're the same _conceptual_ workspaces. There are two different workspaces, with different language ids, and communicating with different language servers. A better way to approach this would be to have a (language-id, workspace-root-uri) => workspace mapping instead of the current workspace-root-uri => workspace one, which would allow lsp-mode to chose the correct workspace object based on the language.

[Vonfry]

Whether there is a function to switch workspace or restart workspace with current mode(lsp-restart-workspace is based on what we have used, not the major mode being used.)

I cannot find such a function. I think this may be a temporary solution.

[mkleehammer]

I could not agree more with @vibhavp - many projects have multiple languages and the configuration files are usually in the root. Having multiple clients based on the language (from major mode) and root is a critical item.

[yyoncho]

See also: https://github.com/emacs-lsp/lsp-mode/issues/424 . LSP mode should support not only multiple languages in one workspace but multiple lsp servers for one file.

[shackra]

I was working in a React course and got hit by this bug when trying to edit a CSS file after opening a JS one.

How is going this to be fixed? is there any plans of accepting or rejecting the pull request of #287? then what should be done about #424 and finally after all that how will be affected the suggested approach of mapping workspaces with language-id and workspace-root-uri?

[yyoncho]

I am planning to work on fixing #424 #287 #293 #292 #390 #376 #360 #359 #340 #319 #285 #105 with one CL which implements what I have described https://github.com/emacs-lsp/lsp-mode/issues/293#issuecomment-423728467 if there is an agreement on the approach. But before that I want to have #409 reviewed/merged which blocks my progress in lsp-java (https://github.com/emacs-lsp/lsp-java/issues/48) and dap-mode.

[shackra]

BTW, not sure if #439 can be taken into consideration, is an annoying behavior that you can workaround by saving the file to disk, but, still.

[shackra]

@yyoncho it seems you are all set and ready to give this issue a try :P (just saw the update on https://github.com/emacs-lsp/lsp-java/issues/48 )

[yyoncho]

@shackra I have started working on that, it will take some time.

[shackra]

Yay!