bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: bug#59214: [PATCH] Alternate rust-analyzer command added
Date: Thu, 17 Nov 2022 21:49:06 +0000

On Thu, Nov 17, 2022 at 6:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Thu, 17 Nov 2022 18:11:32 +0000
> From: "M. Ian Graham" <hello+emacs@miangraham.com>
> Cc: 59214@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, João Távora <joaotavora@gmail.com>
>
> Pankaj Jangid <pankaj@codeisgreat.org> 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.

FWIW, I think Rust is too crazy for us to follow its daily changes and
offer support for its server OOTB in eglot-server-programs.  Emacs is
not equipped to follow such frequent and radical changes.  If we want
to make this seamless for users of Rust, we should provide a special
command to update eglot-server-programs with whatever it is the latest
Rust fashion.  Or maybe we should even leave that to Rust mode.

Yes, indeed, my thoughts exactly, especially this last bit.

In fact, I once idealized eglot-server-programs itself as a temporary thing,
to be superseded by a eglot-server-program buffer-local variable set
by major-modes (and hence more apt and equipped to deal with these
endless variations).  This plan isn't necessarily a priority right now.

João

reply via email to

[Prev in Thread] Current Thread [Next in Thread]