Waiting on reply for this first.

vim/vim#7748

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@prabirshrestha: it looks like the Vim issue itself is stale. What is the path forward on this topic?

I"m looking into trying to run multiple servers so you can edit multiple projects at once in the same session but with different root_uri and instead servers are then looked up by root_uri and not filetype/server_name.

I just want LSP functions to persist between multiple projects of same filetype
(currently the first root_uri sticks and only way to switch between projects is kill server first then open the new project to re-initialize it with new root_uri)

I can run 2 gopls servers with different root_uri, but I also receive response from both at the moment (locationlist opens with 2 results for goto-definition for example) so I will have to look into adapting that code as well.

I hope its possible :)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@prabirshrestha I think the stale bot is pinging you :)

dezza@6d06793

dezza/vim-lsp-settings@6c9ecc0

autocmd BufEnter *.go source ~/.vim/pack/voom/start/vim-lsp-settings/settings/gopls.vim
autocmd BufRead * call lsp#enable()
autocmd VimEnter * call lsp_settings#init()

I did something like this back when I got multiple servers per root_uri working - naming each server with their root_uri. The most cumbersome is enabling the lsp server as vim-lsp assumes one server and the same for terminating the servers. The servers are terminated fine when you :bdelete a buffer as far as I remember, but there might be other cases it doesn"t as I saw a few servers spawned. Another caveat to this is that it starts another server for every goto-definition for imported stdlibs which I didn"t see an obvious way to fix (How to tell if its a stdlib that can be resolved by same server? Or how to tell if its NOT a stdlib?)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I haven"t had time to finish this, I don"t know this project well enough to know what parts it would affect without trial and error.

But it is #1 reason my friends are staying on coc.nvim which does something similar.

The goto-definition question seems to be the hardest to get right (only start a new server if its not a stdlib where you can reuse any server really)

vim-lsp has assumption of 1 server per language.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I tried looking at neovim"s dictionary watch but it isn"t a straight port. So if someone is willing to have custom apis for workspace more than happy to include it without waiting for vim to have a specific api for it.

Yes, please :)

The lack of multi-root support is the main reason why I still use coc.nvim instead of lsp.vim.

I looked at the spec and seems like it isn"t hard to implement and can be done without waiting for upstream vim support.

Before we begin the implementation can folks tell me how they are using it in other editors/lsp client? Even better if you have a sample repo that you can share.

1. Are you using it for a mono repo so that it automatically knows detects the workspace folder for you? For example, if the buffer hasn"t been loaded check if there is a root for that project by using root_uri function, i.e. package.json or Cargo.toml, go.mod and so on and then auto load the workspace folder so there is no user interaction needed.
2. Use cwd() if 1 doesn"t work.
3. Add a function/command to manually add and remove workspace folders of users choice.
4. Support well known workspace folders such as vscode/sublime text. Do we really need this? Can we avoid this?

Basically is it automatically or manually detecting the appropriate workspace folders and if automatic how good is it at.

Definitely a good one to have as a high priority.

@dezza can you let me know which lang server you are using so we can verify it when we do add this feature.

@dezza can you let me know which lang server you are using so we can verify it when we do add this feature.

gopls mainly

It sounds like there are two aspects to multi-root support:

1. Core support, it is the ability to pass a list of root folders to language servers when initializing them. It could be up to the user to configure this list (see my initial post for how coc.nvim does that).
2. Auto-detection, to avoid/reduce the need for manual configuration of the root folders.

Personally I only need the core support, i.e. a way to tell vim-lsp about my root folders. I don"t mind about auto-detection (as long as there is a way to disable it), but I have no opinion about how it should work.

Note that auto-detection is a feature on top of the core support, so IMHO it makes sense to start with core support and re-assess later if auto-detection is really needed.

Auto-detection is however the reason people are using coc.nvim and other solutions instead, because it just works. There are far too many languages where its quite the showstopper as soon as you have things divided in different packages and hardcoding is too much tinkering per active project you develop on, it will become real messy quick.

Please give #1265 a try for initial workspace folder support. Instructions in the PR.

This is now supported in master, please refer to #1265 on the usage.

I uninstalled vim-lsp-settings and tried the settings from the PR.

I also tried vscode on the side to verify how gopls works. The workflow on vscode was to Add folder to workspace and 1 gopls server was running at all times with no experimentalWorkspaceModule initialization option, so it works out of the box with 1 server.

I guess the root_uri is only set up the first time the server is launched, thats why it doesn"t work like I expect.

What I expect is that when I open a first file main.go (gopls initialized with root_uri) and then edit next buffer in another project with two files main.go and db.go that I can still gd goto-definition in the second project opened.

That works as expected in vscode (after adding the second project to workspace). In coc.nvim I guess they start multiple servers for whatever reason.

The solution must be to use the upcoming "add folder to workspacefolder" to add folders as buffers are opened and then it should work like vscode or coc.nvim I hope.