Start only one rust-analyzer in different workspace root files

[xzbdmw]

Neovim version (nvim -v)

0.10

Operating system/version

macos14.2

Output of :checkhealth rustaceanvim

==============================================================================
rustaceanvim: require("rustaceanvim.health").check()

Checking for Lua dependencies ~
- WARNING dap not installed. Needed for debugging features [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap)

Checking external dependencies ~
- OK rust-analyzer: found rust-analyzer 1.76.0 (07dca489 2024-02-04)
- OK Cargo: found cargo 1.76.0 (c84b36747 2024-01-18)
- OK rustc: found rustc 1.76.0 (07dca489a 2024-02-04)
- OK debug adapter: found codelldb 

Checking config ~
- OK No errors found in config.

Checking for conflicting plugins ~
- OK No conflicting plugins detected.

Checking for tree-sitter parser ~
- OK tree-sitter parser for Rust detected.

How to reproduce the issue

open two rust file at different folders.

Expected behaviour

start two rust-analyzer instance as lspconfig do/

Actual behaviour

the two different project share signle server. This makes nvimtree sync with cwd broken, make session manage plugin broken.
Why does the nvimtreetoggle command keep switching between different cwds? Because lsp modified cwd, when I switched to the second workspace, lsp still ran in the workspace of the first file, as can be seen from Lspinfo.

rustacean: start only one server, cause cwd to change when toggle tree.
https://github.com/mrcjkb/rustaceanvim/assets/97848247/b4240ee6-19c5-4926-bee5-3e160de65e71

mason+lspconfig: start two server, file tree woks fine.
https://github.com/mrcjkb/rustaceanvim/assets/97848247/1515726b-f40e-493f-b28c-6852c18f6e9b

The minimal config used to reproduce this issue.

default config

[mrcjkb]

Hey 👋

Starting a single client and registering workspace changes via workspace/didChangeWorkspaceFolders is the intended behaviour.

This sounds like a bug in nvim-tree.

Converting to a discussion.

[xzbdmw]

But lspconfig handles this differently，other server that not active is running in single file mode and don’t cause these issues

[mrcjkb]

Oh, you mean when opening standalone files that are not part of a Cargo project?
That's a rust-analyzer issue.

See :

• [upstream] rust-analyzer attaches, but doesn't work for second standalone file #190

and

• Proper support for standalone/detached files  rust-lang/rust-analyzer#14318

The way lspconfig handles it is not something I want to implement for this plugin, as it can potentially lead to other issues (e.g. spawning too many processes when navigating outside of a project).

[xzbdmw]

What I mean is that when I open a file in another workspace, the inactive lspserver runs in single file mode, If I switch back to the original file at this point, the inactive file will return to the mode with a workspace.

The third one is the active file before I switch and now become inactive thus running in single file mode

[mrcjkb]

I see. Again, this is the intended behaviour. See also this comment on a related lspconfig issue.

Please keep in mind that Neovim has no concept of a workspace. That is something that is implemented by plugins like project.nvim.
If nvim-tree (or some project management plugin you're using) is using the LSP client's config.root_dir as the source of truth to set the cwd or for the current buffer's project root, and is ignoring the workspace_folders, that's a bug.

It should be using the client's workspace_folders property, comparing the uris with the current buffer's path, and then fall back to the config.root_dir if it can't find a match in the workspace_folders.

If I have two files from different Cargo projects open, these are the workspace_folders:

> :lua =vim.lsp.get_clients()[1].workspace_folders
{ {
    name = "/home/mrcjk/git/github/forks/nvim/rocks",
    uri = "file:///home/mrcjk/git/github/forks/nvim/rocks"
}, {
    name = "/home/mrcjk/git/github/forks/tuxedo-rs",
    uri = "file:///home/mrcjk/git/github/forks/tuxedo-rs"
} }

It looks like project.nvim uses root_dir as the source of truth.

[xzbdmw]

Thank you for your patient answer. I disabled project.nvim and everything is fine, Do you have any other suggestions for similar plugins:)

[mrcjkb]

No problem 😄

I have project.nvim installed myself, so I opened a PR with a fix.
It looks like the plugin hasn't been touched in about a year though, so I don't have high hopes about it getting merged anytime soon.

Personally, I haven't really needed it, because I mostly use tmux (and tmux-sessionizer) to switch between projects.
That's why I never noticed the bug :)