Opening a file in emacs with lsp-mode and rustic is *super slow*!


I am really confused by lsp, and how it works in emacs. I think something is my setup is weird, because every time I try to open a rust source file in emacs, it takes forever and the fans goes bananas for a while until it's done doing whatever it is that's triggered by opening a file.

First it say something about metadata

Then it starts spinning up for some heavy duty work, now the fan is blasting full bore

The finally it settles down and I can edit my source file

As I finally decided this was too annoying, I started to look what was running while the computer was so busy.

There were a bunch of these running:

cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/ggeztest/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/tui-rs/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/serialize/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/dua-cli/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/rustlings/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/sdl_test/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/cli-args/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/Sousa/Cargo.toml --all-targets
cargo check --workspace --message-format=json --manifest-path /home/ante/src/Rust/id3-tool/Cargo.toml --all-targets

Why all those? I was trying to open one of those projects, not all of them!

Then I also saw a bunch of rustc running. Why?! I was opening a file, I never asked for it to compile anything, even less 50 big projects! Rust is known for long compile times, I just want to open a file, not compile anything...

If someone can tell me what's going on, I'd love to hear it. I was bad to begin with, and has now grown to be a major PITA.

Starting lsp-mode for a buffer will first start rust-analyzer which requires running cargo check. This can take a while but you only need to do it once per project, after that opening a new file in a project should be much faster.

If you want to open a rust source file without staring lsp-mode you can do that, but rustic will start the lsp process when the buffer is created. This seems intentional, rustic is a sort of 'batteries included' mode. You can probably customize rustic to avoid this.

But why if I open the file foo/src/ why is cargo check then running for bar/src/ and qux/src/ and then also compiling stuff?

Not sure. Are these projects part of a single workspace? Othet than that I can't say offhand what might cause this. Perhaps something in your configuration is strange - even the initial load for a project shouldn't take very long and happens in the background so you should be able to edit the file immediately (without lsp capabilities)

Something in my configuration might indeed be strange. I have checked based it on and checked it against this blog post but see no divergences I understand being that far off.

But, you ask something which strengthen my impression I have no idea how this is supposed to work. What is a workspace? How do I make a source code project be, and what would the effect be?

I can run that cargo check in my foo/src folder and it terminates in a second, just fine. No compiling happening either.

I might add that if this is not the right forum, I'm open to suggestions. I don't understand if this is rust-analyzer, emacs or any of the emacs packages doing this.

It's not the wrong forum, but some place r-a or emacs specific may have more people with ideas. (Please drop a note if you cross-post).

This kind of the core of my problem. I understand zilch about lsp, which means I have no idea how it is supposed to function, and thus if I have made an error.

I can't really ask at an Emacs forum without having lsp and rust-analyzer knowledge in the same room.

But, if I figure it out, I'd share it wide, as this is quite a problem.

I don't have any specific advice, but I can confirm that I don't see this sort of behavior where rustic runs cargo check for every project. I'm using Doom Emacs, if you want to reference their config doomemacs/modules/lang/rust at master · doomemacs/doomemacs · GitHub

Hope this gives you some clues!

Apparently lsp-mode will start rust-analyzer recursively on each "project" it think belongs in its "workspace". I think I got the terminology correct, as "workspace" seems to mean many different things.

It looks like for some reason lsp-mode imagined its "project root" was my src/ directory, and thus all the Cargo.toml files beneath it were dependencies. So, if I opened one of those rust source files, all "dependencies" would be checked and compiled! So just like @yuriy0 guessed, all projects were part of one workspace, but the terminology didn't mean much to me.

Running M-x lsp-describe-session shows you the "sessions" lsp-mode imagines it's managing, and that can apparently be used to see this in action.

To wipe all ideas of what project is which, you can run M-x lsp-workspace-folders-remove to just zap each and every "workspace" lsp should manage. I did that and then the problem went away.

I'm quite baffled by this situation, but as I find the terminology confusing I must have created the mess. How is still is a mystery.

Super thanks to the helpful people in ##rust on for figuring this out, and directing me to the Discord server for emacs-lsp where further help was found! Also thanks for the helpful suggestions here in this thread.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.