3 ms·
Thinking about it, you're probably right. One thing you're missing for your comment is different field name lengths, which is important because you seem to care
by quietbritishjim 6y ago
Thinking about it, you're probably right. One thing you're missing for your comment is different field name lengths, which is important because you seem to care about alignment of field values:
field1: 1
this_is_a_longer_field: 2
Playing with rustfmt online [1], I found that by default it doesn't do that:
field1: 1
this_is_a_longer_field: 2
As a sibling comment says, you must have an option turned on an option for this, and your complaint is that this option isn't working for these nested structs. I guess that's the risk of not using the formatter in its default configuration. But I agree it probably is a bug.
(You've presumably also got an option turned on for tabs. I honestly think that is quite a niche preference nowadays - cue flame war - so I can see that there would be bugs in that option too. But although you bring up tabs in your comment here and in your blog post, I don't see that it's related to the bug you're talking about. Once the formatter has (incorrectly, you argue) decided to format those lines as "one more level of indentation than the line before", it chooses the correct combination of tabs and spaces to do that.)
[1] https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b13b2aeadf3ca9100538fb9d3cc35ccc https://play.rust-lang.org/?version=stable&mode=debug&editio...
- jmillikin 6y ago> You've presumably also got an option turned on for > tabs. I honestly think that is quite a niche > preference nowadays gofmt always indents with tabs, so I'd argue that it's not _that_ niche. One might also argue that, as a zero-cost abstraction for consistently applying a developer's preferred indent depth, they are the most Rust-appropriate option </s>. > Once the formatter has (incorrectly, you argue) decided > to format those lines as "one more level of indentation > than the line before", it chooses the correct > combination of tabs and spaces to do that.) I'm not sure that's the case. It seems to be correctly aligning it when using spaces, so I think the issue is that somewhere it gets confused about whether to indent or align. A lot of very old indenters will treat tabs and spaces as interchangeable, which is why you see so much poorly-formatted C in open-source UNIX tools.
- nybble41 6y ago> A lot of very old indenters will treat tabs and spaces as interchangeable, …. Indeed. If you're going to align expressions in a file that uses tabs for indentation then you need to use tabs up to the block indentation level, but spaces after that for the alignment. That's the only way to ensure that the lines continue to be aligned for any tab-stop setting. Many editors will mangle this horribly, however, by replacing some or all of the spaces with tabs. If you're using tabs for indentation then you really need to turn on visible whitespace and also disable automatic conversion of spaces to tabs unless you're sure your editor is one of the few that gets it right.