@Jdm2 my setup:
distro: #nixos
shell: #fishshell
env management: #direnv + #nix devshells
history: #atuin
project manager: #cargo
file manager: #yazi
editor: #HelixEditor
lsp: #rustanalyzer + #clippy lints
fmt: #rustfmt
spell ceck: #languagetool
vcs: #git + #gitui (TUI) + #sourcehut
fix #4170 I use this method: inject a function fn __ra_doctest_completion() { ...doctest lines... } So the completion works, then maintain a map between the real code and inject function....
Forcing #Zed to use #beta of the #rust-analyzer for the project is neither trivial nor obvious. It by default calls stable rust-analyzer ignoring rustup's override for the project; on top of that installing rust-analyzer beta using #rustup is non-obvious and doesn't happen automatically with the override to the beta chanel to my disappointment.
Fact #Zed doesn't handle environment variables in settings files doesn't help.
Rust-analyzer has began using CPU in the background. It doesn't do it immediately, but if I leave VSCode open, then I notice that in hour or so, it will start to use 5-10% of CPU just by doing nothing. I have to restart the VSCode to get it to behave.
M-. is so ossum, it never occurred to me to try something else!
Today, I was reading Why Use Structured Errors in Rust Applications? and one of the issues discussed is jumping away from the code you're working on to look at the definition of the error. On the one hand, rust-analyzer makes it really easy to jump to the error, but on the other hand they felt that they sometimes had to do so unnecessarily. In the comments on lobste.rs, matklad mentioned that he recently adopted the habit of splitting the screen first and going to the definition in the split (in Emacs terms, in the other window).
The unsynn! macro turns out to become a #rustanalyzer stress test 🤔 #rustlang
The code is fine, compiles as intended. R-A doesn't agree.
musicmatze 
sntx
Manpacket
Michał Fita
Jari Pennanen
kleine Katze
medium rare bird
oylenshpeegul
cehteh