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: Pankaj Jangid
Subject: bug#59214: [PATCH] Alternate rust-analyzer command added
Date: Thu, 17 Nov 2022 15:48:27 +0530
User-agent: Gnus/5.13 (Gnus v5.13)

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.





reply via email to

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