Subject: bug#59214: [PATCH] Alternate rust-analyzer command added

From: "M. Ian Graham" <[email-masked]>
Date: Thu, 17 Nov 2022 18:11:32 +0000

Pankaj Jangid <[email-masked]> wrote:

> -(defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives '("rust-analyzer" "rls")))
> +(defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives '("rust-analyzer" "("rustup" "run" "stable" "rust-analyzer") "rls")))

I just noticed this quote from the announcement at https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#rust-analyzer-is-now-available-via-rustup :

> At this time, to run the rustup-installed version, you need to invoke it this way:
> rustup run stable rust-analyzer
> The next release of rustup will provide a built-in proxy so that running the executable rust-analyzer will launch the appropriate version.

So the current situation is temporary. A rustup-side fix is coming. Once it arrives, the right answer--even for rustup users--will be "just add what you want to PATH and eglot will defer to your environment." Rustup will do this for them automatically, for the rust version of their preference, and eglot will just work.

In the meantime, as is, rustup users have the option of symlinking rust-analyzer into .cargo/bin or adding its location directly to PATH. Anyone not comfortable doing this is also probably not running emacs from master, so they're unlikely to benefit from a short-term elisp fix until the problem goes away. And if emacs adds code depending on rustup, subsequently removing what should theoretically be a temporary fix will in practice break users remaining on older rustup versions.

Unless I'm misunderstanding the situation above or something has changed since the announcement, to me it seems prudent to wait on rustup's fix and avoid letting emacs develop an opinion about the installation method or version details of external components.

Cheers,
Ian