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

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

[Pankaj Jangid]

* lisp/progmodes/eglot.el (eglot-server-programs): There are two
ways to run rust-analyzer. After adding the rustup component,
users can add rust-analyzer to path and run rust-analyzer directly
or they may run ``rustup run stable rust-analyzer'' command. This
revision adds the 2nd command to the list of server programs.
---
 lisp/progmodes/eglot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 63ebbe6cab..f54c2d2c3a 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -181,7 +181,7 @@ eglot-alternatives
                       when probe return (cons probe args)
                       finally (funcall err)))))))
 
-(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")))
                                 (cmake-mode . ("cmake-language-server"))
                                 (vimrc-mode . ("vim-language-server" "--stdio"))
                                 (python-mode
-- 
2.30.2

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

[Eli Zaretskii]

> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Sat, 12 Nov 2022 17:23:19 +0530
> 
> * lisp/progmodes/eglot.el (eglot-server-programs): There are two
> ways to run rust-analyzer. After adding the rustup component,
> users can add rust-analyzer to path and run rust-analyzer directly

What do you mean by "add rust-analyzer to path"? what is "path" in
this case and why would one add rust-analyzer to it?

Thanks.

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

[Pankaj Jangid]

Eli Zaretskii <eliz@gnu.org> writes:

>> * lisp/progmodes/eglot.el (eglot-server-programs): There are two
>> ways to run rust-analyzer. After adding the rustup component,
>> users can add rust-analyzer to path and run rust-analyzer directly
>
> What do you mean by "add rust-analyzer to path"? what is "path" in
> this case and why would one add rust-analyzer to it?

I meant "link rust-analyzer executable into a directory which is covered
by PATH environment variable". Typically, rust programmers have
~/.cargo/bin directory added to PATH env variable. So the official
rust-analyzer documentation suggests that either you link rust-analyzer
to this location or run using command `rustup run stable rust-analyzer'.

Ref: https://rust-analyzer.github.io/manual.html#rustup

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

[Eli Zaretskii]

> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Sat, 12 Nov 2022 17:52:21 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> * lisp/progmodes/eglot.el (eglot-server-programs): There are two
> >> ways to run rust-analyzer. After adding the rustup component,
> >> users can add rust-analyzer to path and run rust-analyzer directly
> >
> > What do you mean by "add rust-analyzer to path"? what is "path" in
> > this case and why would one add rust-analyzer to it?
> 
> I meant "link rust-analyzer executable into a directory which is covered
> by PATH environment variable".

Then please modify the commit log message to use "PATH", upper-case.

> Typically, rust programmers have
> ~/.cargo/bin directory added to PATH env variable. So the official
> rust-analyzer documentation suggests that either you link rust-analyzer
> to this location or run using command `rustup run stable rust-analyzer'.
> 
> Ref: https://rust-analyzer.github.io/manual.html#rustup

I'll defer to João in the decision of whether we want to support both
methods or just one of them.

Thanks.

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

[Pankaj Jangid]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> I meant "link rust-analyzer executable into a directory which is covered
>> by PATH environment variable".
>
> Then please modify the commit log message to use "PATH", upper-case.
>

Sure. Attached is the updated patch.

>> Typically, rust programmers have
>> ~/.cargo/bin directory added to PATH env variable. So the official
>> rust-analyzer documentation suggests that either you link rust-analyzer
>> to this location or run using command `rustup run stable rust-analyzer'.
>> 
>> Ref: https://rust-analyzer.github.io/manual.html#rustup
>
> I'll defer to João in the decision of whether we want to support both
> methods or just one of them.

Sure. Just to add to my pitch. The additional method is a fallback that
I added because I do not touch the ~/.cargo/bin directory by hand and
let `rustup' handle this. There may be few other users like me.

Of course decision is João's.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Alternate-rust-analyzer-command-added.patch --]
[-- Type: text/x-diff, Size: 1370 bytes --]

From 7915d320d87acbb807dde00acd9ce2c8237ed048 Mon Sep 17 00:00:00 2001
From: Pankaj Jangid <pankaj@codeisgreat.org>
Date: Sat, 12 Nov 2022 17:21:56 +0530
Subject: [PATCH] Alternate rust-analyzer command added

* lisp/progmodes/eglot.el (eglot-server-programs): There are two
ways to run rust-analyzer. After adding the rustup component,
users can add rust-analyzer to PATH and run rust-analyzer directly
or they may run ``rustup run stable rust-analyzer'' command. This
revision adds the 2nd command to the list of server programs.
---
 lisp/progmodes/eglot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 63ebbe6cab..f54c2d2c3a 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -181,7 +181,7 @@ eglot-alternatives
                       when probe return (cons probe args)
                       finally (funcall err)))))))
 
-(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")))
                                 (cmake-mode . ("cmake-language-server"))
                                 (vimrc-mode . ("vim-language-server" "--stdio"))
                                 (python-mode
-- 
2.30.2

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

[Eli Zaretskii]

> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Sat, 12 Nov 2022 17:23:19 +0530
> 
> * lisp/progmodes/eglot.el (eglot-server-programs): There are two
> ways to run rust-analyzer. After adding the rustup component,
> users can add rust-analyzer to path and run rust-analyzer directly
> or they may run ``rustup run stable rust-analyzer'' command. This
> revision adds the 2nd command to the list of server programs.
> ---
>  lisp/progmodes/eglot.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 63ebbe6cab..f54c2d2c3a 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -181,7 +181,7 @@ eglot-alternatives
>                        when probe return (cons probe args)
>                        finally (funcall err)))))))
>  
> -(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")))
>                                  (cmake-mode . ("cmake-language-server"))
>                                  (vimrc-mode . ("vim-language-server" "--stdio"))
>                                  (python-mode
> -- 
> 2.30.2

João, what is the procedure for handling the submissions such as this
one?  Should we ping you and wait for your decision, or are you okay
with installing such additions based on our own judgment?

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

On Wed, Nov 16, 2022, 17:05 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Pankaj Jangid <pankaj@codeisgreat.org>
> > Date: Sat, 12 Nov 2022 17:23:19 +0530
> >
> > * lisp/progmodes/eglot.el (eglot-server-programs): There are two
> > ways to run rust-analyzer. After adding the rustup component,
> > users can add rust-analyzer to path and run rust-analyzer directly
> > or they may run ``rustup run stable rust-analyzer'' command. This
> > revision adds the 2nd command to the list of server programs.
> > ---
> >  lisp/progmodes/eglot.el | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> > index 63ebbe6cab..f54c2d2c3a 100644
> > --- a/lisp/progmodes/eglot.el
> > +++ b/lisp/progmodes/eglot.el
> > @@ -181,7 +181,7 @@ eglot-alternatives
> >                        when probe return (cons probe args)
> >                        finally (funcall err)))))))
> >
> > -(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")))
> >                                  (cmake-mode . ("cmake-language-server"))
> >                                  (vimrc-mode . ("vim-language-server"
> "--stdio"))
> >                                  (python-mode
> > --
> > 2.30.2
>
> João, what is the procedure for handling the submissions such as this
> one?  Should we ping you and wait for your decision, or are you okay
> with installing such additions based on our own judgment?
>

Additions  of servers in eglot-server-programs can be installed freely
according to your judgement. Deletions and replacements based on reports of
stale/unmaintained/deprecated servers as well, but feel free to ping me.

Here, we would need and rust expert to explain why the the middle entry is
different or more useful than the first one. I'm not that expert, but
Pankaj's rationale looks reasonably sane. So maybe delete the simple
"rust-analyzer" one? Or maybe not. But two entries for the same server
looks odd. As i said, this must be looked at by someone with knowledge of
rust toolchain and configuration idioms.

João

>

[-- Attachment #2: Type: text/html, Size: 3354 bytes --]

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 16 Nov 2022 17:14:11 +0000
> Cc: Pankaj Jangid <pankaj@codeisgreat.org>, 59214@debbugs.gnu.org
> 
> Here, we would need and rust expert to explain why the the middle entry is different or more useful than the
> first one. I'm not that expert, but Pankaj's rationale looks reasonably sane. So maybe delete the simple
> "rust-analyzer" one? Or maybe not. But two entries for the same server looks odd. As i said, this must be
> looked at by someone with knowledge of rust toolchain and configuration idioms.

For starters, maybe Pankaj could provide more details to answer your
questions?  Perhaps after talking to a Rust expert?

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Wed, Nov 16, 2022 at 7:31 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 16 Nov 2022 17:14:11 +0000
> > Cc: Pankaj Jangid <pankaj@codeisgreat.org>, 59214@debbugs.gnu.org
> >
> > Here, we would need and rust expert to explain why the the middle entry
> is different or more useful than the
> > first one. I'm not that expert, but Pankaj's rationale looks reasonably
> sane. So maybe delete the simple
> > "rust-analyzer" one? Or maybe not. But two entries for the same server
> looks odd. As i said, this must be
> > looked at by someone with knowledge of rust toolchain and configuration
> idioms.
>
> For starters, maybe Pankaj could provide more details to answer your
> questions?  Perhaps after talking to a Rust expert?
>

After thinking about it some more, I think this case is comparable to
ensuring 'serverx' is available in PATH/exec-path, which is something
that we already ask users to do (not only for LSP servers). So I'd say
don't
change the value.  Users can always try out new server invocations
with C-u M-x eglot (I do this all the time, and because the resulting
session is reasonably long lived and the invocation is persisted in
history,
sometimes I don't even bother to edit eglot-server-programs at all).

Pankaj, is it really that uncommon to have a tool installed as part of
a Rust package be in the execution path of a shell? It's not uncommon
in other toolchains with what I think are similar package architectures,
such as Node JS.

João

[-- Attachment #2: Type: text/html, Size: 2250 bytes --]

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

[Stefan Kangas]

João Távora <joaotavora@gmail.com> writes:

> After thinking about it some more, I think this case is comparable to
> ensuring 'serverx' is available in PATH/exec-path, which is something
> that we already ask users to do (not only for LSP servers). So I'd say
> don't change the value.

The difference is that rust-analyzer itself recommends using the rustup
invocation as an alternative to adding the language server to PATH.[1]

I also don't see any downside to adding it.  The variable will get a
tiny bit uglier perhaps, but the benefit is that a real hurdle will be
eliminated for users.  That's a win in my book.

Footnotes:
[1]  https://rust-analyzer.github.io/manual.html#rustup

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

[Pankaj Jangid]

Stefan Kangas <stefankangas@gmail.com> writes:

> The difference is that rust-analyzer itself recommends using the rustup
> invocation as an alternative to adding the language server to PATH.[1]
>
> I also don't see any downside to adding it.  The variable will get a
> tiny bit uglier perhaps, but the benefit is that a real hurdle will be
> eliminated for users.  That's a win in my book.

Yes. That's exactly my thought. I have updated the patch accordingly.

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

[Pankaj Jangid]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

João Távora <joaotavora@gmail.com> writes:

> Pankaj, is it really that uncommon to have a tool installed as part of
> a Rust package be in the execution path of a shell? It's not uncommon
> in other toolchains with what I think are similar package architectures,
> such as Node JS.

Perhaps I wasn't clear enough.

The rust toolchain is similar to the tools of NodeJS world. Both try to
install packages/components in a standardised location. And users are
not required to move files and create links manually using OS level
commands like `cp', `ln' etc. `npm' and `rustup' commands do that for
users.

From the rust users mailing, as far as I have understood, the
maintainers are seeing `rust-analyzer' as a replacement for `rls'. And
`rust-analyzer' was recently moved from `nightly' to `stable'. They have
not yet placed `rust-analyzer' executable in PATH/exec-path, possibly
because they don't want to keep two executables for the same job. Or may
be they are thinking of keeping the name `rls'. Not sure though. But
`rustup run stable rust-analyzer' will work in all cases.

So my recommendation is that we keep just the `rustup' version and `rls'
as fallback. I have attached the updated patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Invoke-rust-analyzer-using-rustup.patch --]
[-- Type: text/x-diff, Size: 1516 bytes --]

From 727e362e142ae3d292bf7abed3b592e0dff36725 Mon Sep 17 00:00:00 2001
From: Pankaj Jangid <pankaj@codeisgreat.org>
Date: Thu, 17 Nov 2022 11:25:16 +0530
Subject: [PATCH] Invoke rust-analyzer using rustup

* lisp/progmodes/eglot.el (eglot-server-programs): There are two
ways to run rust-analyzer. After adding the rustup component,
users can add rust-analyzer executable to PATH/exec-path using OS
level `cp' or `ln' commands and then run rust-analyzer directly or
they may run ``rustup run stable rust-analyzer'' command without
making PATH changes. 2nd command is the preferred way to invoke
the language server because it doesn't require user to manually
create link inside `~/.cargo/bin'.
---
 lisp/progmodes/eglot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 12808e80c4..fb95313aa0 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -181,7 +181,7 @@ eglot-alternatives
                       when probe return (cons probe args)
                       finally (funcall err)))))))
 
-(defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives '("rust-analyzer" "rls")))
+(defvar eglot-server-programs `((rust-mode . ,(eglot-alternatives '(("rustup" "run" "stable" "rust-analyzer") "rls")))
                                 (cmake-mode . ("cmake-language-server"))
                                 (vimrc-mode . ("vim-language-server" "--stdio"))
                                 (python-mode
-- 
2.30.2

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

[João Távora]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
> So my recommendation is that we keep just the `rustup' version and `rls'
> as fallback. I have attached the updated patch.

I'll let you guys make a decision but consider maybe consider these
simple questions when making it.

1. If I was to start developing rust today as a average programmer but
   Rust newbie and I installed one of these "stable" or "nightly"
   things, which one would I probably pick?  And would I have a
   'rust-analyzer' executable in my PATH as a result of that?

2. What are the odds that a average Rust programmer understands a
   message telling her

     "Searching for program: No such file or directory, rust-analyzer"

   and endeavors to create a 'rust-analyzer' script with sth like

     #!/bin/sh
     rustup run rust-analyzer

   somewhere in this config?

   Node JS/NPM also has this 'npm link' which creates a global link to a
   given specific version of an NPM package, and that includes ensuring
   its executables are in the PATH.  Is there such a thing in RustVille?

3. What are the chances that an average Rust programmer stumbles across
   the Eglot manual and reaches:

   (with-eval-after-load 'eglot
      (add-to-list 'eglot-server-programs
                   ("fools" "--stdio")))

   And understands what to do?

4. The 'rust-analyzer' executable that was once, somehow, an
   out-of-the-box thing, right?  Why is it not anymore?  Is it
   temporary, i.e. it coming back in the future?  Or does Rust frown
   upon these things and inequivocally prefers 'rustup run' from now on?
   Or was it never an out-of-the-box thing?  If so, why is it in
   eglot.el as if it was?

5. If you take away the current 'rust-analyzer' entry, how many bug
   reports from annoyed users will we get? 0? 1? Million?

João

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

[Pankaj Jangid]

João Távora <joaotavora@gmail.com> writes:

> 1. If I was to start developing rust today as a average programmer but
>    Rust newbie and I installed one of these "stable" or "nightly"
>    things, which one would I probably pick?  And would I have a
>    'rust-analyzer' executable in my PATH as a result of that?

If the installation was done using `rustup', as described in the
official page - https://www.rust-lang.org/tools/install, then
`rust-analyzer' executable will not be in PATH.

But as pointed out by Ian, there may be other users who are following
alternate installation methods. So keeping one or the other in server
programs will be annoying for at least one set of users.

> 2. What are the odds that a average Rust programmer understands a
>    message telling her
>
>      "Searching for program: No such file or directory, rust-analyzer"
>
>    and endeavors to create a 'rust-analyzer' script with sth like
>
>      #!/bin/sh
>      rustup run rust-analyzer
>
>    somewhere in this config?
>
>    Node JS/NPM also has this 'npm link' which creates a global link to a
>    given specific version of an NPM package, and that includes ensuring
>    its executables are in the PATH.  Is there such a thing in RustVille?

If user has installed rust-analyzer using some other package manager
from their distribution then this problem won't occur. But if user is
following the `rustup' path then there are features like `rustup which'
that user can use to find the location of executable and then create a
link in an accessible location. It will not be difficult for a GNU/*nix
user. But windows users will have to add the whole directory (return by
`rustup which') in PATH.

I can speak for myself though. It is easy for me to create that
link. But I don't want to touch the directory which is managed by
`rustup'. It would be best if `rust-analyzer' works out-of-box if I just
install, Emacs and Rust (via rustup). Then I would just say,

(add-hook 'rust-mode-hook #'eglot-ensure)

> 3. What are the chances that an average Rust programmer stumbles across
>    the Eglot manual and reaches:
>
>    (with-eval-after-load 'eglot
>       (add-to-list 'eglot-server-programs
>                    ("fools" "--stdio")))
>
>    And understands what to do?

If user is conversant with Emacs, this is ok. If the user is new to
Emacs as well, then he/she might have some difficulty understanding
this.

> 4. The 'rust-analyzer' executable that was once, somehow, an
>    out-of-the-box thing, right?  Why is it not anymore?  Is it
>    temporary, i.e. it coming back in the future?  Or does Rust frown
>    upon these things and inequivocally prefers 'rustup run' from now on?
>    Or was it never an out-of-the-box thing?  If so, why is it in
>    eglot.el as if it was?

I am not sure about this. I have never seen this in my PATH. May be
because I just use `rustup' to install/update, like I use `apt' in
Debian.

> 5. If you take away the current 'rust-analyzer' entry, how many bug
>    reports from annoyed users will we get? 0? 1? Million?

After reading Ian's arguments, I feel that it is best to keep both --
rust-analyzer and rustup ... -- to make it convenient for both
non-rustup users and rustup users.

So the first patch was more suitable.

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

[M. Ian Graham]

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 '(("rustup" "run" "stable" "rust-analyzer") "rls")))

Another open question and source of future bug reports: How does a rustup user make eglot work with the nightly release channel when stable is specified here?

Nightly is required by some libraries, and a minority of people use it in development for improved error messages and other benefits.

Are we asking those people to redefine eglot-server-programs?

Cheers,
Ian

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

[Pankaj Jangid]

"M. Ian Graham" <hello+emacs@miangraham.com> writes:

> 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
>> '(("rustup" "run" "stable" "rust-analyzer") "rls")))

Given your valid arguments, the 1st patch would be recommended. Not the
above. Earlier patch was,

-(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")))

> Another open question and source of future bug reports: How does a
> rustup user make eglot work with the nightly release channel when
> stable is specified here?

> Nightly is required by some libraries, and a minority of people use it
> in development for improved error messages and other benefits.
>
> Are we asking those people to redefine eglot-server-programs?


Wow. This is good observation. Here is how rustup users do it. And maybe
I need to update the patch accordingly.

There are two ways to select the toolchain. One is the `rustup default
nightly' command. This sets the nightly toolchain globally. Another
approach is to create a file `rust-toolchain' in the project root
directory and just write the name of toolchain for the project; just
write `nightly' or `stable' on the first line and save. This is like
setting node version in `.nvm' file. Just for the project.

Also `rustup which rust-analyzer' command tells us the full path of the
`rust-analyzer' executable based on active toolchain. Inside Emacs, the
project specific setting (via rust-toolchain file) would be tricky to
pick up. But this will work for globally configured default toolchain.

Should we probe using `shell-command-to-string' and then insert the
value in `eglot-server-programs'? My suggestion would be that, we
include the stable `rust-analyzer' in Emacs and user can always override
if he/she wants to experiment.

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

[M. Ian Graham]

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.

Cheers,
Ian

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

[Pankaj Jangid]

"M. Ian Graham" <hello+emacs@miangraham.com> writes:

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

Agree. Then we just wait for the next release of `rustup'. Anyway that
will happen before the next release of Emacs. So this patch is not
required.

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

[Eli Zaretskii]

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

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

[M. Ian Graham]

Eli Zaretskii <eliz@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

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4018 bytes --]

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

[Pankaj Jangid]

João Távora <joaotavora@gmail.com> writes:

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

Agree.

And thank you, Ian, for bringing up the counter thoughts in the
discussion. It was an eye opener for me. I was thinking `rustup' is the
only way to use `rust'.

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

[Eli Zaretskii]

> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "M. Ian Graham"
>  <hello+emacs@miangraham.com>,  59214@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 10:43:02 +0530
> 
> João Távora <joaotavora@gmail.com> writes:
> 
> >> 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.
> >
> 
> Agree.
> 
> And thank you, Ian, for bringing up the counter thoughts in the
> discussion. It was an eye opener for me. I was thinking `rustup' is the
> only way to use `rust'.

So what's the bottom line here?  Do we need to make any change in
eglot.el, and if so, what change is that?

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

No, I think we came to the conclusion that there's nothing
to be done.  "rust-analyzer" is a good current candidate
for an executable and it will be an even better candidate
soon, as the rustup folks have announced, because they
too will soon providel an executable in PATH named exactly
like that.

So I'm closing this bug.
João


On Fri, Nov 18, 2022 at 8:29 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Pankaj Jangid <pankaj@codeisgreat.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  "M. Ian Graham"
> >  <hello+emacs@miangraham.com>,  59214@debbugs.gnu.org
> > Date: Fri, 18 Nov 2022 10:43:02 +0530
> >
> > João Távora <joaotavora@gmail.com> writes:
> >
> > >> 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.
> > >
> >
> > Agree.
> >
> > And thank you, Ian, for bringing up the counter thoughts in the
> > discussion. It was an eye opener for me. I was thinking `rustup' is the
> > only way to use `rust'.
>
> So what's the bottom line here?  Do we need to make any change in
> eglot.el, and if so, what change is that?
>


-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 2557 bytes --]

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

[M. Ian Graham]

João Távora <joaotavora@gmail.com> wrote:

> Pankaj, is it really that uncommon to have a tool installed as part of
> a Rust package be in the execution path of a shell? It's not uncommon
> in other toolchains with what I think are similar package architectures,
> such as Node JS.

Hello from the peanut gallery and no this is not at all uncommon.

At minimum, guix/nix users avoid rustup (as they do other convenience installers like nvm, gvm, etc) to keep project-specific toolchain versions out of the global environment.

Quantitatively, more mac+homebrew users installed rust-analyzer directly this month than installed rustup. Those users have rust-analyzer in PATH and (probably) no rustup.
https://formulae.brew.sh/formula/rust-analyzer
https://formulae.brew.sh/formula/rustup-init

Personally, my main language is rust and I haven't used rustup in years. It is useful but strictly optional. Requiring it for access to rust-analyzer will break working setups.

If we're adding a new dependency on an optional installation method, can we also please retain the "add rust-analyzer to PATH and eglot will just work" current behavior as well?

Thanks,
Ian

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Thu, Nov 17, 2022 at 8:12 AM M. Ian Graham <hello+emacs@miangraham.com>
wrote:

>
> If we're adding a new dependency on an optional installation method, can
> we also please retain the "add rust-analyzer to PATH and eglot will just
> work" current behavior as well?
>

So rustup is just an optional way of installing rust-analyzer? If so I
think we shouldn't
tweak this.

João

(tangent:  rustup being optional is intriguing and interesting. If I wanted
to learn Rust, just Rust, should I start with a rustup-less setup?)

[-- Attachment #2: Type: text/html, Size: 947 bytes --]

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

[M. Ian Graham]

João Távora <joaotavora@gmail.com> wrote:

> So rustup is just an optional way of installing rust-analyzer?

Rustup is not required, only recommended for new developers.

See Rust's installation guide, which also describes how to add components to PATH when using rustup:
https://www.rust-lang.org/tools/install

See also the next page's description of other installation methods for people who have "Preference for the system package manager" or "Preference against curl | sh" (!):
https://forge.rust-lang.org/infra/other-installation-methods.html

> If I wanted to learn Rust, just Rust, should I start with a rustup-less setup?

The docs above do a good job of breaking down reasons for different installation methods. I'd take their word over mine, but IMO the biggest factor is whether you prefer learning bottom-up and adding complexity as you go, or top-down and having unfamiliar pieces managed for you. Rustup is a top-down, "just works" sort of tool.

If you're an emacs user comfortable with other CLI compilers, you'd be absolutely fine starting with your preferred package manager's "install rust" command and working from there for the bottom-up approach, assuming your distro packages the standard installer. Using this gives you rustc+cargo, which is the equivalent of node+npm, go+subcommands, etc. If that's not available, rustup is fine too!

Cheers,
Ian

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Thu, Nov 17, 2022 at 9:01 AM M. Ian Graham <hello+emacs@miangraham.com>
wrote:

>
> If you're an emacs user comfortable with other CLI compilers, you'd be
> absolutely fine starting with your preferred package manager's "install
> rust" command and working from there for the bottom-up approach, assuming
> your distro packages the standard installer. Using this gives you
> rustc+cargo, which is the equivalent of node+npm, go+subcommands, etc. If
> that's not available, rustup is fine too!
>

Indeed, I'm definitely a bottom-up guy these days.  Many thanks for the
tips.
I'm using archlinux, I think it carries a good rust package.

João

[-- Attachment #2: Type: text/html, Size: 1007 bytes --]

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

[Pankaj Jangid]

João Távora <joaotavora@gmail.com> writes:

> So rustup is just an optional way of installing rust-analyzer? If so I
> think we shouldn't
> tweak this.

It may be optional, but it is *the* official method advertised in the
docs. Other methods are categorised as, as expected, "Other Installation
Methods".

> (tangent:  rustup being optional is intriguing and interesting. If I wanted
> to learn Rust, just Rust, should I start with a rustup-less setup?)

I would recommend `rustup'. Rust is a fast moving language and other
installation methods are not officially maintained. And distribution
providers may have a delay of few days before pushing latest release.