cargo/rustc can already provide all its output as structured json, including the appropriate byte position to apply substitutions suggested in help blocks.
I'm pretty sure that's already how it works yeah, then yeah maybe adding some smarts to ALE is the right thing to do here? Unclear without looking into it more.
I haven’t used ALE in a while, and my colleague who uses vim uses CoC, but as far as I understand, rust-analyzer should “just work” with ALE. You may need to install rust-analyzer (via cargo) and tell ALE to use it, potentially? There’s an older and not well maintained language server called RLS. I would be surprised if ALE defaults to that one, but that could be part of why you aren’t getting great tooling out of the box if so.
I did find this blog post, which seems to suggest there may be a bit of extra config required to get rust-analyzer going with ALE: https://petermalmgren.com/rc-batch-day-9/
Yeah I think maybe I'll just come around to rust-analyzer? My experiences with language servers has been really spotty: they lose the state, eat CPU, want to autocomplete everything, etc. But idk, if it's a "this is the way" thing, I guess part of learning is adopting the customs. Just feels a little disappointing I can get by with like goimports/gofmt/go vet in Go, but there's no analog in Rust.
Oh no, the nice thing about it is you can basically configure it to do whatever you want. You can choose linters or fixers, lint/fix on save or on a configured "I've left insert mode" lag, etc. etc. It's actually really amazing [0].
One of the things I've really enjoyed about the Free Software ecosystem is choice, like mostly before Rails the attitude was "we don't presume to know the best anything, here are some options." I'm not saying there aren't tradeoffs (complexity, bitrot, 7 half-baked options vs. 1 incredible one), only that I kind of low-key resent the "opinionated" software that's out there. I guess I don't really see it as opinionated (like I think Rails' convention over configuration was actually a pretty good idea and exemplifies the "execute" phase of the explore/execute cycle of tooling), I see it as "flashy and targets the 80% use-case to get mindshare".
To be clear, I don't think rust-analyzer is that opinionated or flashy or lazy. I think it's awesome. But Rust's linting story is essentially "why would you use anything besides rust-analyzer, language servers are awesome and have no downsides." Which like, yeah they do.
Oh cool I didn’t know that ALE was so flexible, thanks!
And yeah rust-analyzer is definitely the happy path, but if you were trying to get by without a language server (not going to lie on a very large rust project rust-analyzer’s RAM usage can get up there), I think that `cargo check` output properly parsed and displayed in your linter would probably get you a huge portion of what you need. Between that and rustfmt, I think the only thing you’d be missing would be go to definition and that kind of thing (but you can set that up with a ctags-style thing or just replace with fuzzy grep).
In fact, before I figured out how to get rust-analyzer working in emacs, I used a setup where `cargo check` ran on save, and the output showed up in flycheck. From what you said about ALE, it sounds like you could set it up the same way. The main thing would be making sure there’s a way to get the FULL output of `cargo check`, probably not inline because there tends to be a lot of it. But e.g. with emacs I get error underlines that show the first part of the error, and then I can expand that in a popup window, or run cargo check, which opens cargo check in another buffer, with the output parsed so that if I press enter on an error, it brings me to the location in the code.
All of which is to say that it is doable! Maybe it would just take some extra ALE configuration, since the defaults are probably oriented towards people who are using rust-analyzer.
