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).

[Waridley]

I just didn't realize that rustfmt was governed by a BDFL. If the default Rust style guide was decided by an RFC process, why can't the tool that the entire community insists that everyone must use allow that community to have opportunities to discuss changes they would like to see? Again, I'm not asking for it to be immediately implemented without discussion, or for anyone else to do the work. I'm just asking for it to be open for discussion.

[calebcartwright]

@karyon - well said, thank you

@chylex @Waridley - I think you may have misunderstood what I was saying in https://github.com/rust-lang/rustfmt/issues/887#issuecomment-951478568 so allow me to clarify. There's now two topics being discussed on this issue, the original feature request of the issue, and a more general topic @LikeLakers2 raised as part of a rationale for the requested feature, but which is a much more high level topic that's above and beyond this or any other specific feature request.

My comments you are referring to were made strictly and directly in response to that new general topic @LikeLakers2 raised which I felt obliged to address given the overarching nature. I thought that was pretty clear given that the comment was made directly against the associated quote, which as I'm sure folks realize is a pretty standard practice in tools like GitHub that don't support threaded discussions, but apologies if that caused any confusion. Please don't take a direct response to one quoted comment out of context, nor assume it applies to something else.

The only thing I've said so far that was applicable to the original request of the issue was 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.

And again, I'm aware that's not the answer some of you were hoping to hear. However, I continue to believe that's a pretty reasonable posture, and is the same bar any configuration request we receive has to clear (e.g. #4893, #4835, etc.).

As you can tell by perusing the issue backlog, we receive a lot of customization requests, all of which is potential work in addition to the ongoing support, maintainence, core/default formatting requirements, etc. of rustfmt.

Each of those requests is important or significant the reporter, but that doesn't necessarily make it a top priority for us. There's a lot of requests that have a lot of user engagement and desire from a significant chunk of our user base, and that of course does factor into prioritization considerations. However, this particular request really hasn't generated that broad an interest over the 5+ years of its existence. That's not intended to be a commentary on the nature of this request, nor the benefits/importance of it that you all feel it carries, but is simply an observation of activity compared to other higher traffic/interest requests. 4-5 people over 5+ years really isn't that much, especially compared to many of the other requests we receive.

After a certain point of time, issues that don't have much activity, no community proposed implementation, etc. get closed; that's just the nature of a backlog of work in a larger open source project. That, in combination with the fact that I'd expect even the simplest version of this option to require some pretty pervasive changes throughout the codebase, is why I'm not going to reopen it. However, please refer to my previous statement on our posture. No one said any and all PRs will be refused and I'm happy to be proven wrong if someone can propose a simple, complete solution that clears the bar.

As it relates to the request itself and cursor jumping behavior in editors, I understand and experience this too (though it doesn't bother me personally), but I'd suggest that editor feature/behavior comparison is the wrong lens to compare against an automated formatter like rustfmt. In my experience the stripping of trailing whitespace characters on empty lines is pretty standard behavior for formatters, e.g. gofmt (Go), prettier (JS/TS/etc.), clang-format (C/C++/etc.), black (Python - though admittedly a different whitespace story with python) all do this by default, and to the best of my knowledge, none of them provide an option to keep/insert whitespace characters on blank lines either. I think RuboCop may optionally support this, and it's also true that we don't make decisions strictly based on decisions made for other formatters, but wanted to note the request is not exactly a common, much less ubiquitous, feature in automated formatters.

As such I think it's pretty reasonable for the feature to not already exist and to not be a priority.

[calebcartwright]

@LikeLakers2 re: https://github.com/rust-lang/rustfmt/issues/887#issuecomment-952110881, I understand your question/argument, and that you're trying to use it as part of an argument for this feature request. However, I feel like it's off topic/too broad and adding noise/confusion to the actual feature request on this issue, and would suggest that we take if offline or into a separate issue if you'd like to continue the discussion on that topic.

The final response I'll give here on that topic on this thread is that no, it's not a goal to be able to only emit styling that users want/permit. Most code formatters, including rustfmt, are opinionated (via the community RFC'd Style Guide in rust's case), and it's not a goal for them to support configuration to cover every single subjective case.

I think the underlying sentiment of Rob Pike's quote on gofmt: Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. is generally a pretty apt description of goals and benefits.

You'd be extremely hard pressed to find anyone that loves every aspect of the Rust Style Guide, or any formatting style for that matter. There's parts of the Rust Style Guide that I personally don't like/don't prefer, and even the members of the style team that originally coordinated with the community and codified the style guide have aspects they didn't personally like either. However, many of us just roll our eyes/otherwise accept what the formatter does in those cases anyway because the other benefits outweigh those parts we don't like.

Not everyone feels the same, and some don't use formatters because they dislike something too strongly. That's why we also provide options in rustfmt that projects can use to "disable" rustfmt against their projects.

[calebcartwright]

@Waridley - I appreciate your passion and desire for the request. However, the tone and content of your most recent comments are getting too heated, and I'm going to minimize them so that I can keep the thread open in order for everyone to still be able to post comments.

I hope https://github.com/rust-lang/rustfmt/issues/887#issuecomment-952480921 helps provide some clarity and ameliorates any confusion/negative feelings.

I do want to stress that there's unequivocally not a BDFL, so I wasn't really sure what you were referring to in those comments anyway. The Style Guide was defined through a community driven RFC process like many things in the Rust ecosystem, and any subsequent updates go through the same RFC process.

You'll notice that the repo I previously linked to containing the Style Guide (https://github.com/rust-dev-tools/fmt-rfcs) is actually named fmt-rfcs and you can view the entirety of those historical discussions (including the completed RFCs and changes - https://github.com/rust-dev-tools/fmt-rfcs/issues?q=is%3Aissue+is%3Aclosed).

Please feel free to continue engaging in the discussion, but if you choose to do so, I'd ask that you be mindful of the tone and try to keep things more constructive.

[LikeLakers2]

I understand your question/argument, and that you're trying to use it as part of an argument for this feature request. However, I feel like it's off topic/too broad and adding noise/confusion to the actual feature request on this issue, and would suggest that we take if offline or into a separate issue if you'd like to continue the discussion on that topic.

[and the rest]

Looking back on it, I can see how you might think I'm being a bit too general here, though that wasn't my intention.

However, I ask that you reread my comments, trying to understand that I'm saying "I don't like Rustfmt forcing indents to be removed on otherwise-empty lines, because it offers no option to do the contrary", and nothing else. I'm not even trying to say "every part of Rustfmt needs to be configurable."

I hope reading it with that context may make it seem not so off-topic.

Not everyone feels the same, and some don't use formatters because they dislike something too strongly. That's why we also provide options in rustfmt that projects can use to "disable" rustfmt against their projects.

And that's what I'm arguing for here, to make Rustfmt only do this whitespace-trimming when we give it consent (even implicitly through a default setting). As it stands, it is assuming we want it to do whitespace-trimming whether we actually ask it to or not, and not allowing us to say otherwise.

---

Also, this is sort of unrelated, but could you also address this point from @Waridley (https://github.com/rust-lang/rustfmt/issues/887#issuecomment-951536316)? This sounds like a bug to me, so I'd like your take on it. Nevermind, as Waridley pointed out, there appears to be a issue for it at https://github.com/rust-lang/rustfmt/issues/4706.

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.

[chylex]

In my experience the stripping of trailing whitespace characters on empty lines is pretty standard behavior for formatters (...)

For completeness, I want to mention that many autoformatters in IDEs and editors that I use or have used do have this option

• The vast majority of languages supported by JetBrains IDEs include an option "Keep indents on empty lines", with the only major exception being C#
• Eclipse also includes such option
• VS Code lets you disable trimming which also affects empty lines so they keep the indent, but unlike JB autoformatters, VS Code does not fix wrong indents on empty lines
• Visual Studio is missing this option, but at least a plugin is available to fix both problems I have with empty lines

Especially as a current user of many languages across several JB IDEs, I am used to this option being present nearly everywhere. I have not used any autoformatters you mentioned that do not have this option, so our experiences are almost completely opposite.

[Waridley]

chylex Waridley - I think you may have misunderstood what I was saying in #887 (comment) so allow me to clarify. There's now two topics being discussed on this issue, the original feature request of the issue, and a more general topic LikeLakers2 raised as part of a rationale for the requested feature, but which is a much more high level topic that's above and beyond this or any other specific feature request.

My comments you are referring to were made strictly and directly in response to that new general topic LikeLakers2 raised which I felt obliged to address given the overarching nature. I thought that was pretty clear given that the comment was made directly against the associated quote, which as I'm sure folks realize is a pretty standard practice in tools like GitHub that don't support threaded discussions, but apologies if that caused any confusion. Please don't take a direct response to one quoted comment out of context, nor assume it applies to something else.

The only thing I've said so far that was applicable to the original request of the issue was this:

...

Okay, I'm sorry. I think the problem here was that I was perceiving LikeLakers' comment as specific to this issue, and you were perceiving it as more general, and therefore I failed to recognize that your comments weren't directed at this specific topic. Also perhaps I shouldn't have tried to reply on mobile and instead should have waited till I got to my computer.

... 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.

The problem here is that this sounds to me like, "Feel free to waste your time writing a PR, but it probably won't even be considered." If you're really that strongly against adding this option, then I don't want to waste your time reviewing a PR just to close it, either. But if your concern is just how complex this feature will be, then I think that discussion could be had in a PR, after making it clear here that you expect it to be too complex and invasive. Now that you have made this comment ...

No one said any and all PRs will be refused and I'm happy to be proven wrong if someone can propose a simple, complete solution that clears the bar.

... I feel like it might actually be worthwhile looking in to it for myself, but previously I felt like there was no point.

After a certain point of time, issues that don't have much activity, no community proposed implementation, etc. get closed; that's just the nature of a backlog of work in a larger open source project.

The only repos I have experience with that close issues due to inactivity use a bot that automatically closes it after one year, with a comment saying that it can be reopened with a comment if it is still relevant. In this case, the issue was closed manually with no explanation, and won't be reopened even after more users have expressed interest in it. I wasn't even using Rust in 2016, and AFAIK IDE support was quite poor back then, so there may not have been enough users using IDE's with this setting to generate significant discussion on this issue. Then once the issue was closed, I expect that deterred most users from commenting on it. I know I was originally disappointed to see it closed and just moved on. I only wrote my first comment months later after getting irritated again at not being able to change it.

Maybe there should be some other way to handle feature requests if the backlog is too overwhelming? Many larger projects move them to a separate repo. If this feature were low-priority and delayed, I would be content with waiting. What frustrated me was seeing a firm "no" with minimal opportunity for discussion.

You'll notice that the repo I previously linked to containing the Style Guide (https://github.com/rust-dev-tools/fmt-rfcs) is actually named fmt-rfcs and you can view the entirety of those historical discussions (including the completed RFCs and changes - https://github.com/rust-dev-tools/fmt-rfcs/issues?q=is%3Aissue+is%3Aclosed).

You're right, I didn't check closed issues on that repo, but only the current version of the style guide. Now I have found https://github.com/rust-dev-tools/fmt-rfcs/issues/37 which records the decision to not indent blank lines by default. However, I'm not sure why this isn't documented in the actual style guide. There are comments there mentioning that indents on blank lines are "trailing whitespace", which I can understand, but to my mind, they are leading whitespace, followed by a 0-character line of code, followed by a newline character. It seems much more logical and flexible to me to separate the ideas of indentation and trailing whitespace. Since those concepts are separate in my mind, it appeared to me that the style guide made no mention of indents on empty lines at all, which made me wonder why rustfmt did anything with them when it was supposedly primarily following the style guide.

[Waridley]

@LikeLakers2 Actually there is already an issue for that: https://github.com/rust-lang/rustfmt/issues/4706

Though apparently it is similar to another issue that was already solved? If this kind of issue repeatedly occurs, perhaps something is fundamentally wrong with the way rustfmt handles skipping code...

[BenjaminBrienen]

This should be reopened. Removing whitespace from empty lines actually affects my productivity. I shouldn't have to manually indent lines just because I want to add code to a previously blank line. The indentation of a code block should be extremely concrete and solid. Washing away indentations is against the very idea of a code block being indented. Again, I hate that adding a blank line and saving (which triggers a format) causes the indentation to be erased, meaning that I have to manually tab it out when I go to add more code to the program. I like code to be formatted as I type. Removing indentations is not any kind of formatting whatsoever. Removing superfluous indentation, fixing line endings, and such is a job for an entirely different step of the toolchain, and ONLY comes into play when committing source code. It should never even happen to the local file.

[kaya3]

Adding my voice to those who want to see this as an option. This is the main reason I don't use rustfmt myself.

But also, someone else mentioned "messy diffs" as a reason not to have it, and I think that is backwards. In my case, somebody contributed code to one of my projects and inadvertently removed all of the whitespace from the empty lines, creating a diff which was mostly whitespace ─ and I had to merge their contribution manually so as not to merge in the whitespace changes, which I did not want.

It's OK to say that I don't have to use rustfmt if I don't like it, but here it's getting in the way of me accepting contributions from other people who do use it. If this was configurable then I could put it in the project's config file and there would be no problem. I hope that the answer is not that I just have to accept this from other people using rustfmt if I want to accept their contributions, because as other people have mentioned, this is a usability issue, not a stylistic preference.

[calebcartwright]

@kaya3 if you don't want to use rustfmt in your project(s) and you don't want contributors running rustfmt (intentionally or unintentionally) then the standard response applies:

add a rustfmt.toml file to your project, and set the disable_all_formatting option to true

[Clonkex]

This is crazy. Why would any formatting tool remove indentation from empty lines? It should be indented whether it has code or not. Otherwise it's just painful every time I want to add code to a blank line. No other tool does this, so why does rustfmt do it? Or more to the point, why is it not an option? It's not trailing whitespace (except in the pedantic sense) so why is it being removed?

or in this case almost universally, no whitespace after the last non-whitespace character on a line

This is simply not true. I've been programming professionally for 8 years and have used many editors and not a single one removed empty line indentation by default. Obviously no one wants whitespace after the last non-whitespace character on a line containing code, but the indentation should always exist!

Can this please be reopened?

[LikeLakers2]

I apologize, but I have to be blunt to the rustfmt maintainers here.

It's been two years and some change since I made my comments here, asking for this sort of thing. I'm still surprised there's not an inch of progress towards this, especially in the face of so many asking for it.

I get that rustfmt is a code formatter, and an opinionated one at that. I understand some concessions will have to be made, and I understand that implementation of things will move slowly. But right now, it feels like our feelings on this matter are... for lack of a better way to put it, being deliberately and entirely ignored.

And because of that, it upsets me every time I see this issue in my notifications. Every time someone comments here, it's a reminder of how little our words actually seem to matter if none of the maintainers care. It's a reminder of how good rustfmt could have been for so many developers, and yet it isn't.

I want rustfmt to be a tool that everyone uses. But that can't happen unless our opinions are taken into account - and right now, they aren't.

[calebcartwright]

I'm going to lock this because the matter was resolved a long time ago. To reiterate the team's position that's been stated a few times:

This is not something the rustfmt team is going to work on.

There's plenty of other features, some desired by a much greater number of people than this one, which we're not going to work on ourselves either. We're not going to work on it because (1) it's not part of our core focus area (being the implementing tool for Rust's official Style Guide) and (2) we know what a complex implementation effort this would require, we have other higher priorities and don't have the time for this custom feature.

This is an open source project at the end of the day. For those that disagree and think that this custom feature would be easy to implement and reasonable for our team to maintain and support, please feel free to make an attempt to develop it and submit a Pull Request. We wouldn't reject such a PR just for the sake of it, we're simply stating the team's position that it's an infeasible ask of us and our belief that an implementation is impractical based on experience, priorities, and bandwidth.

If you want to see this, then try to implement it. However, attempts to guilt and shame a couple of volunteer maintainers that spend some of their free time on nights and weekends trying to maintain and advance a tool, simply because they wouldn't implement a custom feature you wanted, is not going to be effective and it will not achieve your desired outcome.