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

Previous Next

Full log

Message #82 received at 59214 <at> debbugs.gnu.org (full text, mbox):

From: "M. Ian Graham" <hello+emacs <at> miangraham.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59214 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org, joaotavora <at> gmail.com
Subject: Re: bug#59214: [PATCH] Alternate rust-analyzer command added
Date: Thu, 17 Nov 2022 19:43:39 +0000

Eli Zaretskii <eliz <at> gnu.org> wrote:

> 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.

Completely agreed. I don't think there's a great way to support most Rust devs in a stable Emacs release besides treating Rust like any other language, deferring to normal environment settings, and letting individuals, their configs, and their outside libraries cross the thrash gap to fix defvars, envvars, and other settings as needed.

> 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.

This, however, also sounds like a great enabler to me. Rust devs would gain the option of easily matching the change velocity in their elisp config rather than through env vars, which would probably improve the case of Windows users that Pankaj brought up earlier.

Apologies to the participants for my jumping all over this thread. I'm absolutely in support of improving the new Rust dev experience if Emacs can do it without painting itself into a corner. Rust has a lot of paint. :)

Cheers,
Ian

Previous Next

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