Before this release, using the playground felt like writing code on paper. I constantly had to open docs.rs to check what methods are available, or what is this variable (hmm... Into<T>). Rust Explorer now supports auto-complete, hover, and diagnostics. The language server doesn't block the execution. So you can run code even when the language server runs cargo check.
Rust Analyzer uses a lot of memory. If you find this project useful, consider supporting it on Patreon. So I can add more servers if needed.
There are 3 more features that I think would make the playground complete: go to definition, auto import, and rename. Plus options to remap vim keybinding for vim users like me. I already have in mind how I'll implement "go to definition". It'll be much easier to navigate than in other editors. But for now I'll take a break for a few weeks to focus on job hunting.
I already noticed the changes. It’s quite remarkable in my opinion!
Really, the only problem I still have working with Rust Explorer is that the editor still inserts a second single quote when I’m trying to write a lifetime parameter. I had already mentioned this issue, I don’t quite remember the conclusion whether there was any good way to address the problem, but I’m having a hard time imagining how that could be harder to pull off than the full Rust Analyzer integration.
While I’m at it reporting issues: I now often see the behavior that the output keeps doing the “loading” animation even after the execution has finished. And as far as I can tell, the “start from scratch” button doesn’t really do anything.
And also, wasn’t there an “expand macros” kind of operation possible previously? Unless I’m misremembering this. I think an option for expanding macros is super useful.
Quite frankly, if parsing technology is used to project code i.e. going in the opposite direction to parsing w.r.t. grammar productions, and that was integrated properly into editors, then this kind of thing would be trivial.
In the same vein, matching the angular brackets used for generics could be reliably distinguished from comparison operators.
I'm not sure why this hasn't been done yet; perhaps it's just lack of imagination.
I don't know if there was or not, but it would indeed be pretty useful. Implementing some way to invoke arbitrary lsp commands exposed by rust-analyzer should implement this and more (like structural search and replace). Another option would be to allow invoking lsp assists. There is a rewrite assist for inlining a macro, which has the effect of expanding a single layer of the macro as opposed to recursively expanding it for the macro expansion command.
The typing experience is 100% handled by Code Mirror. Since it's not as a big deal as not having a language server, I'll wait for someone to fix it.
I used to experience it but not recently. If you consistently experience this issue please send me a link to the code.
Yes. Currently it only send you to an empty editor if you're on a saved bin page or history page. I'm afraid that people may accidentally wipe out unsaved code when what they actually want to do is to hit "Run". But that's something to consider.
You're right. I removed "expand macro" and "Clippy" buttons. People rarely use them. I think people that used them are people who just trying the features. They rarely used them again. In the spirit of keeping the playground simple I had to remove them.
I think you're describing Tree-Sitter, which is the parser that inspires Marijn Haverbeke to write Lezer, the parser used in Code Mirror (Rust Explorer's editor).
Tree-sitter could provide the basis for such functionality, yes. But I still haven't actually seen it pop up anywhere, not even in Emacs.
There are a bunch of treesitter-based Emacs modes in development, but I'm not sure if initially they'll actually allow matching eg parens and brackets based on the actual ASTs rather than the current heuristic-based system (which breaks on large inputs).
I'm not familiar with Emacs. I believe some languages on modern editors like VS Code and NeoVim use the LSP coloring feature. So Tree-sitter is not needed when you have a language server that support syntax highlighting. For the web, the experience may be not as smooth because of the latency or when the server temporarily disconnected.
This makes perfect sense to me. I wouldn't want to accidentally delete my code. I believe some kind of visual indicator before or after you press the button when it does nothing might be useful to make it feel more like intended behavior. Or maybe even just an "are you sure?" kind of prompt.. Or maybe open the new bin on a new tab in these cases...
Once it appears, it never goes away anymore as long as my session is ongoing. I’ll try to pay attention how I got there, the next time I come across a consistent way reproduce the issue in a new session.
I think this feature is more valuable than you think; I'd like to join @steffahn and @bjorn3 request regarding the usefulness of this feature
By the way, if having to set up cargo expand on the server is deemed to be a maintainability burden, know that you can manually expand macros using:
cargo rustc -- -Zunpretty=expanded | rustfmt
Besides this, I really like how Rust explorer is architectured; the gigantic dependency tree it has at its disposal keeps me going back to it again and again
