atom-language-rust
atom-language-rust copied to clipboard
Braces don't always lower indentation level
For example, in match statements where a comma follows, or in a closure where a paren-semicolon follows. Neither of those have correct indentation, as they both report one level more than they should. Moving the following characters onto their own line corrects the issue.
While typing it will work fine most of the time, but when pasting code with "Auto Indent on Paste" set to true it causes quite a few incorrect indents.
Below is an example of what happens: (Note the last brace ends the function, not the match statement.)
Edit: Hmm, it's a bit more complicated than that, it seems that sometimes (like in let bindings) it works fine, even if the ending brace has a semicolon after it. And sometimes it works fine in if statements, and other times it doesn't. The source I'm using to test is https://github.com/gfx-rs/gfx-rs/tree/master/examples/deferred
I think now they are overlowering the indentation level to 0. Here's how it looks in my editor:
fn main() {
loop {
| // the cursor position is on column 0
} // autindented to col 0
//...
}
the same indentation happens on every level:
fn main() {
// ...
loop {
match a {
| // the cursor position is on col 0
} // autindented to col 0
}
//...
}
I'm not sure if this behavior can be changed by grammar rules (not that I'm aware of). Since the behavior changed over time, I think they changed something in the Atom editor itself. At the current version (0.182.0) this seems to work well
I still get incorrect indentation when I have multi-line function parameters:
fn foo_multi_line(a: i32
b: i32) {
| <- cursor here
Same problem still exists as described in this post https://discuss.atom.io/t/auto-indent-slightly-off/18198
I just committed some basic indent pattern settings which I took from the language-c package. Indentation behavior is changed with the increaseIndentPattern and decreaseIndentPattern settings. This current settings should work for most cases, but probably could need some adjustments for Rust specifics. Unfortunately I don't have much spare time to dig deeper into it, so I'd appreciate any help.
Issue #35 and #44 are also related to this.