Rls: Atom support

[nrc]

Tracking issue for Atom support.

Existing work: https://github.com/aergonaut/languageserver-rust and https://github.com/mehcode/atom-ide-rust

Checklist (from clients.md):

• [x] Implement extensions to the protocol
• [ ] Client-side configuration.
• [ ] send the workspace/didChangeConfiguration notification when configuration changes.
• [ ] Support all config options, see config.rs
• [x] Check for and install the RLS
• [x] check the RLS is installed, and if not, install it and the rust-analysis and rust-src components
• [ ] be aware that the RLS component is changing name - currently rls, will become rls-preview.
• [ ] you should provide a way to update the RLS component
• [ ] Client-side features
• [ ] e.g., code snippets, build tasks, syntax highlighting
• [ ] Testing
• [x] Ensure integration with existing Rust features, e.g., syntax highlighting
• [ ] 'Marketing'
• [ ] documentation - users need to know how to install and use the extension
• [ ] keep us informed about status so we can advertise it appropriately
• [ ] update the RLS website
• [x] submit the extension to the editor package manager or marketplace

[nrc]

Atom-IDE announcement: https://blog.atom.io/2017/09/12/announcing-atom-ide.html

[nrc]

Added checklist of stuff to do to the OP. There's probably more done than I know about - I've just ticked off what I know for sure about. We should track any bugs or opportunity for polish that come.

[mehcode]

@aergonaut As ide-* are the official names do you want to just move over to ide-rust? I can make you a collaborator.

From a quick glance the difference in our packages is mine installs rustup and rls with a prompt.

---

@nrc

Going to sleep now but I can run through that checklist tomorrow and give updates.

[aergonaut]

@mehcode works for me!

[vertexclique]

I am working on integrating atom-ide to tokamak package. Already it has a lot of things assembled inside of it. You can see whole project features in:

http://vertexclique.github.io/tokamak/

I propose adding all those implementations on top of it is better than creating yet another package.
If you want we can incorporate it into Rust ecosystem.

[mehcode]

Implement extensions to the protocol

Hasn't been done yet. Looks simple enough.

@nrc FYI rustWorkspace/deglob is in the RLS to LSP section when it should be in the LSP to RLS section here.

Client-side configuration.
send the workspace/didChangeConfiguration notification when configuration changes.
Support all config options, see config.rs

These are not done. I understood rls.toml to be where configuration is done per-project. Do the editor settings override rls.toml? Is rls.toml going away? If it is going away, note that Atom cannot reliably do per-project configuration in a general sense (we can define a toml file in the project that we look at, Atom will not though).

Check for and install the RLS

Done.

Check the RLS is installed, and if not, install it and the rust-analysis and rust-src components.

Done. Did you mean for the line above here to be different?

Client-side features ( e.g., code snippets, build tasks, syntax highlighting )

These features are not part of the LSP implementation but I'd agree are part of a good IDE experience. Atom already has notions of where to do these things though.

code snippets should be in the language-rust package. If we want to get more of these, PRs there should work. There is https://github.com/zargony/atom-language-rust/pull/74 already.

syntax highlighting is also in language-rust. It's already quite good at the moment but there are definite improvements to be made. I'd love to see format arguments highlighted, for example.

build tasks - There is a huge ecosystem in Atom for _building_ stuff: https://github.com/noseglid/atom-build
There is https://atom.io/packages/build-cargo already that covers this nicely.

Testing

There is https://atom.io/packages/build-cargo supports this.

Ensure integration with existing Rust features, e.g., syntax highlighting

Yes. ide-rust will not activate without the language-rust package and works with it. Furthermore, Installing ide-rust will automatically install langauge-rust ( and atom-ide-ui ).

documentation - users need to know how to install and use the extension

There exists install documentation. Usage will need to be updated once we have configuration.

submit the extension to the editor package manager or marketplace

Done.

---

@vertexclique

Briefly going over tokamak. It does look very nice. From talking to the Atom team, the ide-<language> packages should exist and be the "official" LSP integration for a language. Could you instead use atom-package-deps to install ide-rust ?

I added you as a collaborator on ide-rust, let's work on the LSP piece there together.

---

Also added you @aergonaut

I won't be able to start working on anything till likely early next week. If you want to get started I'm on IRC or Slack and can help direct you how to do the thing in Atom.

---

@nrc Would you like me to move ide-rust in rust-lang-nursery ?

[vertexclique]

Sidenote:

• Build tasks (clean, build, rebuild)
• Testing
• Auto formatting
• Terminal for running and debugging
• Automatic binary detection like (cargo, rustc etc.)
• Toolchain management
• Project creation
• Project specific configuration

features are included in Tokamak.

[nrc]

I understood rls.toml to be where configuration is done per-project.

rls.toml has been removed we depend on the client for configuration now.

Atom cannot reliably do per-project configuration

Hmm, that is disappointing. What is the likelihood of them addressing this? Seems essential for an IDE to me.

Done. Did you mean for the line above here to be different?

They were meant to be headings and sub-headings, but that is lost in this check-list, sorry.

To confirm on the user experience here, do we get user consent before installing anything?

It should be configurable which branch to use (nightly vs stable vs beta) too.

Atom already has notions of where to do these things though.

I assume the client is required to do some work though to actually specify them?

As a philosophical point, I think a Rust plugin (ide-rust) should be a Rust plugin, not an RLS plugin, so all the client-side stuff is important to include and get right (and track).

~Are dependent plugins a thing in Atom? I.e., can ide-rust require language-rust? If not can we install language-rust as part of the ide-rust setup? Worst-case, we should copy and paste language-rust into ide-rust (I assume other languages deal with this issue too and there must be some kind of ecosystem convention for dealing with this).~ I see you address this in the next point.

Should we do the same thing with build-cargo? We might need tighter integration in the long run - I'd like to be able to use the RLS configuration to supply args to the build tasks, etc.

Would you like me to move ide-rust in rust-lang-nursery ?

I am not sure about this. I am keen to encourage editor extensions to develop their own communities and I'm not sure if adding to the nursery will help or hinder that. Not being in the nursery should not prevent the dev-tools team advertising the extension (e.g., on the Rust website), etc. I think for now it would be good to create an atom-rust org and keep ide-rust under that (and possibly try and get build-cargo and language-rust under that org too. If we decide later the nurser would be better, we can move to the nursery. Does that sound like a good plan?

[nrc]

@vertexclique @mehcode So, I'm not sure what to do about the two different implementations. I agree with @mehcode that we should try and use the official 'ide-rust' name, and I think it would be better for users if there were a single implementation. Tokamak does seem to be further along in terms of implementing features. Do the two of you think there is a good path forward to merge the projects?

[dnsco]

Building with cargo is already supported with the atom build plugin atom-build-cargo. Unfortunately atom-build outputs in the old linter format (linter-indie v1) and atom-ide-ui consumes only the new format (linter-indie v2). As a result of this inconsistency it doesn't show up in the atom-ide-ui-diagnostic-ui panel (which replaces the linter package). Heres the issue with some pointers on the atom-build repo. I'll take a crack at it when I've got time but wont be jealous if I get swooped ;-)

[dnsco]

Unfortunately test failures are not currently parsed properly by anything in the ecosystem that I have found. When I get my shit together I'll send an rfc to rust to make the test formatter be configurable so we can have a machine readable option, but until then, it's hardcoded human-readable, so we need to write a parser or something. /cc @steveklabnik

[damieng]

Atom-ide-ui does support linter v1 although it's a bit more strict than actual linter - I'd check the console for errors.

[sunjay]

So ide-rust is the official plugin I should be using? Atom 1.21 was just released :tada: and it is supposed to have good language server support. (I'm guessing that's why I couldn't install the latest ide-rust until now)

[aergonaut]

Yeah, I think ide-rust should be the promoted one. I'm going to add a deprecation notice to my repository and see if I can mark it as such in apm as well.

[sunjay]

Should I still be using language-rust? Or does ide-rust replace that too?

[aergonaut]

ide-rust will install language-rust if it is not installed already.

You still need language-rust to provide syntax highlighting and language detection. ide-rust is separate and just provides RLS features.

[alexheretic]

I've been working a little on improving ide-rust & rls on atom.

• [x] Client-side configuration.
• [x] send the workspace/didChangeConfiguration notification when configuration changes.
• [x] Support all config options, see config.rs

We have these since https://github.com/mehcode/atom-ide-rust/pull/14. It's currently implemented in a client watched rls.toml file as atom doesn't have a per-project config opinion yet.

Also worth mentioning my Rls changes #534, #552, #565 improve/will improve the performance situation greatly for the atom client.

[alexheretic]

ide-rust 0.11 is now available, it has decent toolchain handling now with update notifications & graceful handling of missing _rls-preview_.

[alexheretic]

ide-rust 0.13 is now out. I'd actually like for this package to be a little better advertised by the rust ide sites. Currently areweideyet.com has:

Atom
Important packages: language-rust, linter-rust (relying on linter), racer, rustfmt,tokamak,build-cargo (relying onbuildand linter), atom-beautify which you can use to run rustfmt, languageserver-rust

So ide-rust really should be mentioned as it's a single-package solution for rust in Atom. It automatically installs _language-rust_ and afaik provides the functionality of the rest.

forge.rust-lang.org/ides.html links to _language-rust_ and here it also might make more sense to link to ide-rust there.

[nrc]

Congrats on the release! I'll mention the release in the next tools news.

The forge page shouldn't exist, it was removed from the repo some time ago but is still live for some reason. I filed an issue to remove it.

I don't know who manages areweideyet.com. I think the best course of action would be to submit a PR to https://github.com/contradictioned/areweideyet.

[alexheretic]

ide-rust 0.14 is out and now mentioned on areweideyet.com.

The latest version brings support for the upcoming _window/progress_ messages from Rls.

[alexheretic]

ide-rust 0.15 is out with, amongst other improvements, support for CodeActions. That means rustc & clippy suggestions.

[alexheretic]

ide-rust 0.16 is now available. It brings global setting of the clippy_preference rls config & other improvements.

Released today as today we have the first Rls nightly with clippy_preference config _and_ clippy actually enabled.

This means you can turn the setting to On and use clippy in all projects without source modification.

[alexheretic]

ide-rust 0.17 is out with detection of potentially conflicting atom rust packages showing a simple notification dialog to allow disabling them, or ide-rust.

This is mostly because of the large amount of rust packages doing the same sort of thing for atom. This should hopefully avoid a whole class of conflict issues, and help people keep their atom a little trimmer.

[sunjay]

Is there a configuration file I can use for ide-rust RLS options? I want to specify which features (i.e. --features foo) to use for a given target.

[alexheretic]

It's mentioned in the readme. A rls.toml file at the project root can be used for all rls configuration.

# rls.toml
features = ["foo"]

[sunjay]

Thanks! I want to specify a particular feature for when the crate is compiled as if it was being tested. (i.e. cargo test --features foo) Is that possible?

[alexheretic]

Any rls config can be used see https://github.com/rust-lang-nursery/rls#configuration.

So you could try the unstable cfg_test = true option, along with enabling unstable options. I'm not sure how well that works with current rls releases though. I've just been using all_targets myself.

[alexheretic]

ide-rust 0.18 is now available. It brings the ability to disable ide-rust/rls on certain project paths.

This is also the first release as part of rust-lang-nursery :tada:

[alexheretic]

ide-rust 0.19

[alexheretic]

ide-rust 0.20.

I'll close this issue now as ide-rust is fairly mature nowadays, ide-rust repo is: https://github.com/rust-lang/atom-ide-rust