How to edit multiple projects at the same time (with rust-analyzer)

[setzer22]

Hi! I'm working in Rust with lsp-mode, using rust-analyzer as the LSP server. So far I've been able to set up almost everything to my liking, but there's one thing VSCode does correctly out of the box and emacs doesn't. I'm not sure how I can fix it, but it's finally bugged me enough to make me dig further into this. I really don't want to go back to VSCode 😬. Let me explain:

I have two Rust projects (crates) I maintain set up as two independent git repositories, and on the emacs side, these map to two separate projectile projects. And one project (let's call it crate_a) depends on the other (crate_b). During development, I like being able to develop both projects at the same time, so I temporarily set up a dependency using a path declaration on my Cargo.toml:

crate_b = { path = "../../crate_b" }

Doing this allows jumping to definition and finding references across the two crates, and it creates a very seamless development experience. But when I do this on emacs with lsp-mode, it starts two separate instances of rust-analyzer, one per project. This means changes I make in crate_b are not visible in crate_a unless I run lsp-restart-workspace (which takes a couple of minutes). For instance, if I add a new function or method in crate_b, the other crate won't suggest it as an auto-completion until I restart.

When calling lsp-describe session, I see two different sessions, one for each project

What I would like instead, is that all the folders are managed by the same LSP instance, regardless of the directory structure.

Is there a way I can achieve this?

Thanks a lot!

[yyoncho]

@flodiebold @brotzeit is rust-analyzer multi-root ready? If yes, then I guess we should simply mark it as such.

[yyoncho]

The solution it should be fine. Using view-mode in lsp-mode is a bit questionable, but it may be convenient. I will leave it as it is.

[setzer22]

Nevermind... Looks like I was too hasty to mark this as solved :/

When I add my project root folder as a library path as suggested, I can jump to definition to files in crate_b, but only the file I navigate to seems to get loaded by emacs-lsp, so actions like lsp-rust-find-parent-module fail, and every time I open a different file, I am greeted by the interactive prompt of "abc.rs is not a part of any project."

This makes the workaround very limited in usability. Unless we can figure out a way to fix this new issue 🤔

[yyoncho]

What different file means here? Is lsp-rust-find-parent-module behaving differently in vscode?

[setzer22]

Let me describe a bit better, using my example above:

• I have crate_a, which is the main project I start editing, and then I occasionally (mostly via "jump to definition") I end up in a file from crate_b.
• As suggested above, the root path for crate_b is in lsp-rust-analyzer-library-directories.
• When I open a file from crate_b, I get the " is not a part of any project." prompt, asking me to interactively select an option. I press i to select the autodetected project root.
• Then, I can edit the individual file from crate_b, and going back to crate_a, changes are shown. When checking lsp-describe-session, I can only see an lsp server, with the project root for crate_a. However, there's a couple of issues.
• If, from that file in crate_b, I try to jump to another file in crate_b (say, via "jump to definition"), I get the interactive prompt again. Selecting i every time seems to work, but it's a bit cumbersome.
• If I haven't navigated to the parent and answered the interactive prompt before, calling the function lsp-rust-find-parent-module returns an error. The equivalent function in VSCode has no trouble jumping to the parent folder when you're visiting a "library" file.

I think this pretty much sums it up 👍

[setzer22]

Having thought a bit about this, I think I'd the simplest solution for me would be some kind of mode / toggle / patch that simply doesn't attempt to autodetect the current project, and only spawns a single lsp server, sending all requests to that same server. I tend to use separate emacs processes for separate projects, so the feature to have multiple LSP servers spawned by the same emacs process is not all that useful to me. I understand this is not how everyone uses emacs, but I'd be happy if you could help me find a workaround for my use case 🙂