Skip to content

README: add two rust-analyzer configuration examples for Neovim users #9939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sruggier wants to merge 3 commits into
base: main
Choose a base branch
from
Open

README: add two rust-analyzer configuration examples for Neovim users #9939

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8cf7461
README: rejoin key tips list with the paragraph that follows it
sruggier Feb 27, 2026
4b2f0fa
README: add two rust-analyzer configuration examples for Neovim users
sruggier Feb 27, 2026
9e46438
README: add a warning about rust-analyzer's memory usage
sruggier Mar 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 42 additions & 2 deletions README.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,8 +81,17 @@ NOTE: This section assumes you're already familiar with the prerequisites and en
* Use `cargo check` when you just want to know if your code compiles. It's _much_ faster than `cargo build` or `cargo nextest run`.
* When using Cargo's check/build/test/clippy commands, you can use the `-p PACKAGE` flag to only operate on a specific package. This often saves a lot of time for incremental builds.
* When using Cargo's check/build/clippy commands, use `--all-targets` to make sure you're checking or building the test code, too.
* Beware of rust-analyzer's memory usage, which can easily be over 12 GB per
process. If you spawn multiple instances of it for this codebase, whether by
using multiple instances of vim, multiple editors, or some combination of
editors and coding agents, it's easy to accidentally overwhelm your system.
Consider using something like https://codeberg.org/p2502/lspmux[lspmux] (or
https://github.com/sunshowers/lspmux-rust-analyzer[sunshowers/lspmux-rust-analyzer])
to prevent this from happening.
* Use https://rust-analyzer.github.io/book/configuration#cargo.targetDir[`cargo.targetDir`] to give rust-analyzer a target directory other than `./target` so it doesn't block you from running commands in the terminal. This uses extra disk space.

These are explained a bit more below, along with some common pitfalls.

.How to set `cargo.targetDir` in various editors
[%collapsible]
====
Expand All @@ -93,12 +102,43 @@ NOTE: This section assumes you're already familiar with the prerequisites and en
[language-server.rust-analyzer.config]
cargo.targetDir = true
----
.Neovim (using rustaceanvim)
[source, lua]
----
vim.g.rustaceanvim = {
server = {
default_settings = {
['rust-analyzer'] = {
cargo = {
targetDir = true,
},
},
},
},
}
----
.Neovim (using LazyVim): merge the following into custom.lua
[source, lua]
----
{
"mrcjkb/rustaceanvim",
opts = {
server = {
default_settings = {
["rust-analyzer"] = {
cargo = {
targetDir = true,
},
},
},
},
},
},
----
Comment on lines +105 to +137
Copy link
Contributor

@sunshowers sunshowers Mar 4, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this.

Unfortunately my understanding is that this will cause each neovim instance to spawn an r-a process which can cause the system to run out of RAM rather quickly (r-a on Omicron routinely takes 12+ GB).

I wrote up a small tool which integrates lspmux with r-a to solve this issue:
https://github.com/sunshowers/lspmux-rust-analyzer. (We also have an internal variant of lspmux which isn't open source, and which I didn't realize existed before I wrote this.)

All of this is to say that I'm concerned about recommending something which makes it too easy for people to shoot themselves in the foot. Maybe one of us should work on productionizing some kind of lspmux + r-a thing, whether the FOSS version + my scripts or our integration.

Copy link
Contributor Author

@sruggier sruggier Mar 5, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, also, for your response 🙂

To be fair, these snippets merely set cargo.targetDir in rust-analyzer's config, whereas the behaviour of spawning r-a processes is triggered by installing the rustaceanvim plugin, or bootstrapping a LazyVim config and installing lang.rust from :LazyExtras.

Still, that can be a lot of memory usage, and the added concurrency enabled by setting targetDir would increase the risk of thrashing somewhat. Not that I have any strong feelings about getting this merged, but I pushed a commit that adds a warning about the memory usage, with links to both of those repositories. It seemed like a relatively uncontroversial next step, but that's not to say I want to discourage any other feedback about it.

I didn't attempt to mention the internal variant of lspmux: you can probably do a better job of that than I can, having some knowledge of where it lives. It's kind of funny, though, that you went from duplicate rust-analyzer processes to duplicate lspmux repositories.

Copy link
Contributor Author

@sruggier sruggier Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, is there some kind of prize if I manage to beat the high score? I started loosely paying attention to rust-analyzer's memory usage after you mentioned it, and it's now above 17 GB on my system 😂

Copy link
Contributor Author

@sruggier sruggier Mar 10, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another funny addendum here: the omicron codebase has made a Helix user out of me. The experience of navigating clippy diagnostics, at least in my Neovim setup, was too slow to incorporate into a development workflow, and it turns out Helix implements that in a much more useful way.

Edit: I'll add that based on my own experience using the two, I think it would even be reasonable to suggest to Neovim users interested in working with this codebase that they should consider switching to Helix.


====


These are explained a bit more below, along with some common pitfalls.

Here's an example workflow. Suppose you're working on some changes to the Nexus database model (`nexus-db-model` package, located at `nexus/db-model` from the root). While you're actively writing and checking code, you might run:

```
Expand Down