Option to preserve indent in empty lines.

[kevincox]

Hello, it would be nice to have the option to put whitespace on empty lines to match the current indent level.

fn foo() {
   let thing = 1;
   <- Keep this indent.
   let thing = 2;
}

[sbstp]

Is there a particular reason why you want this? Keeping whitespace on empty lines can create really messy diffs. A lot of editors already trim lines too.

[kevincox]

It is personal preference like most formatting settings. I like being able to easily position my cursor on an empty line and also have my editor configured to display indentation so that I can easily follow the levels.

Also I don't see why the diffs would be messy. And if editors trim the lines that's what a formatter is for :)

[daboross]

One reason editors and tools almost universally strip whitespace off of the empty lines is in cases between two lines with different indents, it may be hard to judge which indent to take, and that could lead to unnecessary diff changes in commits with different editors/tools, as well as confusion when editing the library. Example:

fn function() {
    {
        inner_function_call();
// how much indent here,  8 spaces or 4?
    }

    really_long_method_call(inner_argument_1, inner_argument_2, inner_argument_3,
            inner_argument_4, inner_argument_5);
// how about here? 12, 4, or 0?
}

This is also somewhat related to the standard of removing all whitespaces from the end of lines (e.g. changing ...;<whitespace here> to ...;).

The diff thing is somewhat related as well: in general, there are few tools which will specifically format whitespace on empty lines to a specific length, so all whitespace on empty lines which ends up being committed to repositories is purely because of someone forgetting to remove it - this leads to an inconsistent amount of whitespace on different lines, and if no one updates it, or if different tools update it differently, it can end up adding completely unrelated lines to a git diff or patch file.

This is somewhat similar to the issue of mixing tabs/spaces in a repository: if the only person who updates it updates it inconsistently, or if some editors format with spaces and others with tabs, many, many unnecessary changes can be added to a patch file leading to merging hell. The solution being to agree on one standard: spaces for indentation, or in this case almost universally, no whitespace after the last non-whitespace character on a line. Straying from the standard is OK, but it usually has more downsides than upsides. For example, if someone is trying to contribute to your project, and if they're editor is configured, as many are, to immediately remove all end-of-line whitespace, they'll have to either manually re-add all of the whitespace, change their editor setting, or, more likely, submit a pull request with many more lines changed than would otherwise have been required.

If you like being able to keep your cursor position constant when scrolling, many editors I've seen do have the option to allow caret placement past the end of the line, allowing it to seem like there's whitespace there without actually saving any. Also, I'm only really trying to criticize the choice you've made a little bit - you are completely free to choose to have whitespace on empty lines. I'm just trying to provide some of the reasoning behind not allowing it, and why it probably isn't the highest priority to add to rustfmt (I wouldn't know about this, as I am not a contributor, but just guessing).

[kevincox]

@daboross I see your point about where the indent should lie. But unlike python I think the answer is usually quite clear in rust.

fn function() {
    {
        inner_function_call();
        // It is inside the scope so 2 levels of indent.
    }

    really_long_method_call(inner_argument_1, inner_argument_2, inner_argument_3,
            inner_argument_4, inner_argument_5);
    // It is outside of the argument list, but inside the outer scope so 1 level.
}

In all cases I can think of the indent could be sanely, and consistently defined.

[daboross]

That is true, and I guess my post isn't really an argument against including this in rustfmt - mostly a reason for why it isn't done in general or why it hasn't already happened.

I guess the only reason for not including it would be the confusing factor for people who would be possible contributors to projects with a 'add-whitespace' setting enabled. Most programming editors I know remove whitespace at the end of lines / on empty lines by default, so this would just cause a small change submitted by someone possibly turning into them attempting to commit a large style change without realizing it.

The only other thing is having whitespace at the end of a line is usually warned against in command line versions of git and other tools, and specifically it would/will make using git merge and git diff more complicated. Git uses empty lines to separate changes, so it will just be more work merging branches with such a setting enabled.

The two above things are mostly what people meant by messy diffs I believe. It might be harder to see the problem if you haven't used the command line tools a lot, but it also really wouldn't be too large of a problem if everyone consistently uses rustfmt with the same settings.

[chylex]

Unfortunately some of the most common IDEs and editors (IntelliJ, VS Code) don't work well at all when indents are stripped from empty lines. It makes navigation so confusing when the cursor constantly jumps left and right, and typing on empty lines requires additional reformatting which is very annoying.

Sadly that's a blocker for me, I cannot use rustfmt or accept PRs that use rustfmt if they keep messing up indents and making navigating and writing code more difficult.

many editors I've seen do have the option to allow caret placement past the end of the line

Every editor I've seen with this option allows caret placement infintely past the end of the line, not just on the indent. In terms of code navigation, that's actually even worse than unindented empty lines in my opinion.

[Waridley]

Frankly I don't understand why this issue is closed as if it won't be fixed, instead of allowing potential PR's if someone wants to implement it.

We're not trying to argue about which way is correct or should be the default (of course the default should stay exactly what it is now even if the alternative were "better" just so it doesn't break anything). We're just trying to allow users to make the decision for their own code. They can have the argument in their own repositories if they want to change the default.

[LikeLakers2]

I'm curious if this issue could be reopened? I can't really see a reason to leave this closed, unless we're assuming this setting isn't wanted (though it very clearly is).

Anyways, here's my take: Rustfmt should not be editing indents (whether removing or adding them) on otherwise-empty lines, unless it also provides a configuration option for such a change (even if such an option were a simple boolean). To do otherwise is to force a code style onto users that they may not like -- that's pretty bad for rustfmt to be doing!

[calebcartwright]

I'm curious if this issue could be reopened?

Sorry, but no I'm not going to reopen this. This is not something the rustfmt team will work on, nor do we want to actively solicit any contributions/imply that it may be worked on.

As with any open source project, there's nothing preventing anyone sufficiently motivated from submitting a pull request. However, review/consideration would be an extremely low priority, and as is the case with any configuration option, it would have to be weighed on the merits against the impact on the codebase, maintenance, bug surface area, etc.

I realize that's not what some were hoping to hear, but that remains the position and we're not going to be changing that.

To do otherwise is to force a code style onto users that they may not like -- that's pretty bad for rustfmt to be doing!

Thanks for sharing your perspective, but I have to say that's tough to reconcile with the core purpose of code formatters which inherently do enforce a specific code style.

There's an official Rust Style Guide that went through exhaustive debate to identify a reasonably good/acceptable style for Rust code. rustfmt's purpose is to take an input program and rewrite it in a way that complies with that style, regardless of the original formatting. rustfmt is a full blown pretty-printer style formatter so that it can achieve that goal, as well as aiding in the broader goal the style team had to strive for style consistency across Rust codebases.

rustfmt is still configurable (arguably significantly more so than similar-style formatters in other ecosystems), but it's not a design goal to provide a configuration option for everything, especially when an option would add undo complexity and complicate the primary formatting function.

Remember that the core purpose of code formatters is not to produce a style that's unequivocally "beautiful" to every single developer, nor to provide an infinitely controllable feature set so that it can be used to produce a bespoke style unique to every developer. The real value prop is automating the formatting process in a consistent and predictable manner, so that the humans don't really have to think about it and can focus on actually writing code.

It's entirely up to you whether to use an automated formatter, but if you decide to use one, then I'd advise being prepared for the automated formatter to apply its own formatting style.

[chylex]

I understand your points and agree with some, but I would like to point out that indents are not about "beauty" - after all it's invisible whitespace - but about usability which is more important than how code "looks".

I find it ironic that one of the arguments is about letting humans focus on writing code and not thinking about formatting, when removing indents makes me constantly think about formatting because as I said earlier, it makes navigation in code jarring and requires additional mental effort when editing empty lines. That to me is a usability issue, and ultimately the reason why I decided against using rustfmt, not because of any subjective "beauty" of the code.

[Waridley]

@chylex I completely agree with this. This is literally the only issue preventing me from using rustfmt, and to call this usability issue "bespoke" is obstinate and insulting.

Also, maybe I'm failing to find the correct section or search terms, but I find nothing in the style guide saying anything one way or the other about whitespace on blank lines. It doesn't seem to even mention trailing whitespace (perhaps because it's considered obviously undesirable, but it's the only other thing I can think of that would result in any modification of whitespace on blank lines whatsoever).

This issue has actually recently caused an erroneous error in the one repo I am actually trying to use rustfmt for. I marked a section of code with #[rustfmt::skip], and since my IDE had behaved correctly and indented the blank lines for me, rustfmt saw the "trailing" whitespace and thought it failed to remove it. If you really insist that there should absolutely never be any whitespace on blank lines ever, then I guess rustfmt should also remove it on skipped code... But not removing it and then erroring because it didn't remove it is clearly the worst possible behavior. I know this is probably a bug, but since I don't really want to use rustfmt due to this one issue, I'm unmotivated to create a separate issue about it.

I absolutely would be willing to look in to how hard it actually is to add this option, I don't expect the maintainers to do it. But the fact that it clearly would be unwelcome makes me not even want to take the time.

[karyon]

Hi @Waridley, I looked up "bespoke" (non-native speaker here) and the oxford learners dict says it means "made specially, according to the needs of an individual customer". Maybe I'm misunderstanding something, but feeling insulted and calling others obstinate seems to be an unusually strong reaction here.

Generally, all, please remember that the maintainer is a volunteering individual with limited time and energy. They've made a not-totally-unreasonable call and I invite you to make their job not more energy draining than necessary.

[LikeLakers2]

(Sorry for the double post, email users. I realized shortly after my previous (now-deleted) response that I needed to think about my response a little more.)

[@calebcartwright]

To do otherwise is to force a code style onto users that they may not like -- that's pretty bad for rustfmt to be doing!

Thanks for sharing your perspective, but I have to say that's tough to reconcile with the core purpose of code formatters which inherently do enforce a specific code style.

I think you're misunderstanding me here. I am not saying that the core purpose of code formatters is bad. It wouldn't be a code formatter if it weren't meant to force a specific code style.

But a code formatter should do so only with the consent of its users (even if it's through implicit consent via a default setting). As it stands, Rustfmt is not asking for consent to its changes; It is removing indents from otherwise-empty lines while also not providing an option to tell it "no". That's why I find it bad for Rustfmt to be doing this.

Imagine, if you will, that Rustfmt didn't have a hard_tabs configuration. Instead, it enforced one indent style or the other (it doesn't matter which here) on every user that ever used it. In some cases, users may find that okay -- they may agree to the style of indent used, or maybe they simply don't care. But some people may prefer the opposite style of indent. If Rustfmt is forcing them to use the indent style they don't like, with no way to turn it off, they may become averse to ever using Rustfmt.

That's exactly what's happening here: Rustfmt is forcing its own code style upon us, and those of us who disagree with Rustfmt have no way to turn it off. Our only option is to apply the remaining changes (the changes we want) manually, which can turn off people from wanting to use Rustfmt.

Do you understand me now?

[Waridley]

@karyon I called it "obstinate" because it demonstrates a self-centered mindset that assumes, "since I don't want this, no one must want it." And I wasn't really just talking about that one word, but it was an example of the dismissive tone of the whole message.

4 people have cared enough about this feature to find this issue and take the time convey their argument for why it should be considered. We can't know how many people have found it and were disappointed with the decision but didn't say anything, assuming it being closed was the final word. That also doesn't count the people who wish this setting existed but haven't found this issue or didn't take the time to look for it.

It's insulting because it minimizes the real inconveniences that users are experiencing rather than listening to their concerns.

I'm sorry if my reaction seems too strong, but I actually don't mind asking the maintainers to spend a little more effort to listen to us when their indifference costs me extra work and mental effort constantly every single day. I don't get the benefits of rustfmt organizing my imports for me or fixing small formatting mistakes I didn't notice or making my code generally more consistent with other crates, all because of this one decision which I cannot get used to (and don't really want to get used to because I find it highly illogical, but that part is just my opinion).