GNU bug report logs - #59214
[PATCH] Alternate rust-analyzer command added

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59214 <at> debbugs.gnu.org, "M. Ian Graham" <hello+emacs <at> miangraham.com>, pankaj <at> codeisgreat.org
Subject: bug#59214: [PATCH] Alternate rust-analyzer command added
Date: Thu, 17 Nov 2022 21:49:06 +0000

[Message part 1 (text/plain, inline)]

On Thu, Nov 17, 2022 at 6:47 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.