@matklad Hey, so I'm slowly digging into integrating the rust-analyzer into the vscode and been wondering about the current distribution
Looking at the current infrastructure, it seems to be very tied to the current extension and installing it alongside of it
Apart from providing the best experience coupled with a dedicated plugin, is there any other technical reason not to support a regular
cargo install means of distribution?
Is it because we'd like to continue providing rolling releases without the semver hassle?
So, cargo install is supported
or rather, it just works
But it's kind of unpleasant, as it builds stuff from source. Not that building rust-analyzer is hard (we have zero c deps, which is even checked on CI), but it's not super fast
cargo install could do binary packages, we'd do that
ah right, I missed that
I wouldn't call that the infra is reallied tied to the extension.
Publishing-wise, we just ship binaries to GH releases.
On the extension side, we basically need just a path to the
rust-analyzer executable. But we also implement "download from github" thing
I was scouring the code and referred to the cargo xtask install ra
which does a lot of vscode checking and tweaking, hence my original comment
cargo xtask install installs both the binary and the vscode extension
I imagine the alternative is to download the release directly from https://github.com/rust-analyzer/rust-analyzer/releases/download/nightly/rust-analyzer-linux or similar?
btw it feels nice to specify "rust-analyzer" as the LSP server path in the existing extension and most of the stuff just works out of box :)
(modulo applySourceChange and whatnot)
Yup (in VS Code, we do this(=download release directly) in
Argh, applySourceChange is a big one tough
will hopefully taclke it next week
btw why codeaction/textedit from LSP wasn't enough?
We want to control the position of the cursor
The following won't be possible with stock code actions
as well as "ctrl+. on
mod foo; creates&opens foo.rs file"
while we are at it @Igor Matuszewski what are your thoughts on mering TS extensions?
We want to control the position of the cursor
I've looked, and they both clock at around 2k lines of code, which is not that bad
while we are at it Igor Matuszewski what are your thoughts on mering TS extensions?
I think that'd be ideal
I'd host something like a
rust-lang/vscode-rust personally, though
to sort of make it more official/bless it
Which is the high-order bit here? A separate repo, or a
not sure how that would impede the current dev workflow for rust-analyzer, I imagine that's something that has to be talked over separately
I sort-of find it usful to have the typescript and rust code in the same repository
well, both I imagine
Ideally we shouldn't really tie them in any way
Like, we do custom things, and when you hack on a custom thing, it's very conveient to me able to fix both sides at once
I personally feel like this sends a wrong message in the sense that it's only expected to work best for vscode
I too feel the burden when you need to juggle 3 vscode instances, output to a log file and debug the spawned extension, which the more streamlined approach helps with
https://github.com/rust-analyzer/rust-analyzer/pull/3561 is a good example of feature which would be pretty awkward to do across several repos
but I'm not sure that's the right way - otherwise we'd have to lump all of the editors' code together with rust-analyzer
it's only expected to work best for vscode
It's quite literary true though: LSP impls in other editors tend to be sup bar
one thing that is annoying, though, is that you get a lot of bug reports for the vscode extension repository, which 99% should be meant for the LSP itself
as someone who uses RA from another editor (and sometimes updates the integration), I think it's still useful to have one 'reference' implementation
TBH, I'd be happy to have at least VS Code, Emacs and Vim plugins in the repo.
we'll have an official VSCode extension and the official IDE tool as Rust Analyzer, I think that should be easily discoverable for the reference implementation, personally
But at the moment Emacs-LSP preferes a monorepo wit all extensions, and vim has five different LSP plugins none of which is a clear favorite
at least neovim has it easy :stuck_out_tongue:
You mean the neovim-lsp which is in the unrelease 0.5 branch?
the one by autozimu, last time I've checked it's been the most popular one
but then again they added a support for LSP in trunk? or so I recall
I think coc.nvim is known for "works best", and the
nvim-lsp (which I talked above) is going to be build in
I was talking about https://github.com/autozimu/LanguageClient-neovim
should we move the discussion merging off this topic btw?
yup, right, there was a dedidated one