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

[sruggier]

There are multiple different ways one can integrate rust-analyzer into Neovim, each configured slightly differently. Even for Neovim users who aren't covered, though, these examples should help simplify the process of figuring it out.

[sruggier]

For context, this is a side effect of me trying to tackle #9804.

It looks like the most reasonable potential reviewers for this happen to be the set of people who work on this repo that are also named David (@davepacheco and @david-crespo).

Specifically, the top editor of the README file:

$ git log --pretty=format:%an -- README.adoc | sort | uniq -c | sort -nr | head -n 1
     51 David Pacheco

and the person who added the example block this PR expands:

$ git blame README.adoc | grep 'How to set `cargo.targetDir` in various editors'
07ef231aa9 (David Crespo    2025-08-19 19:24:56 -0500  88) .How to set `cargo.targetDir` in various editors

[sunshowers]

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.

[sruggier]

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.

[sruggier]

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 😂

[sruggier]

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.