Provide ability to ignore all whitespace in diff editor (feature request)

[simonl65]

Steps to Reproduce:

1. In settings it's possible to set "diffEditor.ignoreTrimWhitespace": true
2. There's no option to ignore all whitespace,

Would it be possible to add "diffEditor.ignoreAllSpaces": true? I believe the command-line to achieve this would be something like git diff --ignore-space-at-eol -b -w [commit]...

h/t Daniel Gomez @ coderwall

[edit]
Might only need -w ?
[/edit]

[tommck]

It's been over a year and I REALLY would love to have this feature. Any chance it will be implemented?

[vitalyzhynov]

try to install Beyond Compare. It makes possible to configure diffs in any way.
Also sourcetree can help you to configure Beyond Comare.

In vs you will see something like

[tobiasdiez]

It would be also good if differences in line breaks (not just new/deleted empty lines) could be ignored. That is, the following should be taken to be the same:

aaaa
bbb

aaaabbb

[shamoh19]

Ability to Ignore whitespace in Visual Studio Code git diff view for sure will be good feature

Looking forward for that

[ttjackott]

This would be really helpful!

[rendall]

As with everything, I have Thoughts On This.

I suspect that opinionated formatters such as Prettier solve one problem but at high cost.

The problem that formatters solve: whitespace and indentation is consistent across developers and time, so that changes between commits are obvious. This reduces errors and cognitive load when reviewing code and when troubleshooting.

Two problems that they aggravate:

1. Expressiveness and facility is important when coding and reading code, and I would argue this is top priority. Opinionated formatters impose a cognitive load on everyone, making individual coders work harder to read their own code
2. Moreover, this raises the bar for entry for new people, making coding a less inclusive industry

A better solution, in my opinion:
Do away with whitespace as a concern when writing or reviewing code. Do not impose whitespace and indentation formatting constraints for source code if the language itself does not. Each developer can then individually format code according to how each thinks best.

This is why I support this feature request.

As an industry could stand to move away from having opinions about how other developers format their source code, in favor of expressiveness, ease and inclusiveness.

[Lexicality]

Hi @rendall, thanks for your comment. While well written, it doesn't seem to add any new specifications or refinements to the feature request. While we all would like this feature to ship, we should respect the time of the maintainers and, as per the contributing guidelines, avoid making comments that simply express a desire for something to be done. If we are not willing to add the feature ourselves and submit a pull request, we must wait and trust in the prioritisation system this team has developed to help bring us this free product we all enjoy.

[rendall]

Hi Mr. Robinson. Sincerely sorry my opinion rubbed you the wrong way.

While I don't mind, the code of conduct emphasizes friendliness and patience. Is there another way you can give feedback?

Cheers!

[Lexicality]

I do apologise, I have updated my comment to be less caustic.
Incidentally, I use non-binary pronouns. Thank you for your understanding.

[rendall]

Gladly. In case we ever interact again, feel free to share your preferred honorific

[soundneedle]

This would be really helpful even three years later!

[pranavq212]

This would be really helpful even three years later!

@soundneedle, @farmerpaul, @samuelms1, @navneeth-spotnana, @WilliamLHarms This feature already exists in VS code for long now

By default now it is enabled to ignore whitespace. If not you can check click on this button to disable "Show Whitespace":

You can notice if I enable setting "Show Whitespace", it is showing all whitespace changes too.

[lenerdz]

@pranavq212 Thanks!
I was just searching for an hour about this.

[ahernsean]

@soundneedle, @farmerpaul, @samuelms1, @navneeth-spotnana, @WilliamLHarms This feature already exists in VS code for long now

By default now it is enabled to ignore whitespace. If not you can check click on this button to disable "Show Whitespace":

You can notice if I enable setting "Show Whitespace", it is showing all whitespace changes too.

That's not quite what people are asking for. It doesn't ignore all whitespace. It ignores leading or trailing whitespace only.

[gm-lunatix]

Just a ping on this, and an example of formatting changes we'd like to be able turn off and not show in the diff editor (like -w for git diff as someone mentioned previously):

[jmp75]

This is an essential feature. I am currently looking for a breaking change in a git repo that also had uniform formatling applied in between the commits of interest, and this is obnoxiously in the way if using gitlens.

I am longing for the venerable TortoiseDiff winding back to earlier this century:

[johnwest80]

Any progress on ignoring all spaces? The below code is exactly the same - there should be a way to not show it as a diff. Thx!

[SebiTimeWaster]

this is an essential feature, especially when working with libraries from github.

[vhnatyk]

ignore whitespaces needed!!! :(

[wlyssescerqueira]

+1 for this feature, please

[pvihan]

+1

Hi VScode team. Your product is great but lacks one this crucial feature. Source reformatting makes diff impossible (irrelevant whitespace changes). Other competing tools (IDEA, WinMerge, TortoiseGit diff etc.) all have ability to ignore ALL whitespaces. Please consider implementing this.

[nesterscript]

I am working on an extension that ignores irrelevant changes (like whitespaces outside of strings) based on the grammar rules of the programming language. The number of supported languages is quite small so far, but maybe it is useful to some of you.

Hmm. Very interesting. Thank you! Will check now.
P.S. ignore whitespace in VSCode needed anyways.

[FH-Inway]

+1 for the option to ignore all white space.

[Iaotle]

@hediet you self-assigned this a long time ago, are you working on this?

[surfmuggle]

@tobiasdiez i created a feature request to ignore line breaks in diff editor see #198381

[nessadc]

This is really needed please.

[steen16]

Seriously :) 5 years and counting...

[HFTrader]

Not implementing this feature is UNCHRISTIAN

[jacob-thrackle]

Not implementing this feature is UNCHRISTIAN

How dare they, this is AMERICA

[brianjmurrell]

The religious and political side-comments are really unnecessary and unwanted here. They are just noise that you are copying all of the subscribers on this ticket to.

Yes, it's horrible that this issue still exists today but smart-alec comments being spammed to every subscriber is not helping at all.

Yes, I do realize that I am spamming that same subscriber list but I hope it's useful in that it quells any number of future smart-alec-y comments that provide no help and are of no use.

[steen16]

Not implementing this feature is UNCHRISTIAN

How dare they, this is AMERICA

It's not America, it's the world.

[hediet]

I'm probably the only one from our team who is subscribed on this and this noise forced me to unsubscribe...

I'm aware of this issue. There are some technical challenges to get good performance for this and currently there are more important issues to work on.

[ickc]

@hediet, this also affects anyone watching status of any issues. I'd suggest a stronger, organization-wide policy to prohibit this kind of spams and enforce it. If there's any concern that such a drastic measure would alienate users, may I remind that not doing something against these abuses would also alienate other users who behaved civilly, not to mention how this set a bad example to how people should use GitHub generally, making the platform less valuable to developers.

I'd suggest you to report higher up to relevant teams to look into this. I don't think it's your responsibility, but definitely Microsoft's.

P.S. I recently subscribed because I encountered this issue too. I'm unsubscribing after reading this and those before.

[steen16]

@ickc You are the spammer here, complete nonsense and off topic. The reaction by users is very predictable given that such a fundamental feature is taking years to implement.

[HFTrader]

Although the spam factor is not an issue to me (I disable all email Github notifications or forward all to the same mail folder), I feel like it is healthy that people who think this issue is important enough, be able to comment and contribute. I found finicky to complain about users reasserting their need for a feature.

[ickc]

People seem to have no GitHub ethics here. Expressing a desire of a feature should use ways that don’t tricker notification to others, such as emoji feedback.

This kind of toxic behavior is exactly why there should be policy around this.

maintainer, please lock this thread because this is getting uncivil.

[vhnatyk]

People seem to have no GitHub ethics here. Expressing a desire of a feature should use ways that don’t tricker notification to others, such as emoji feedback.

This kind of toxic behavior is exactly why there should be policy around this.

maintainer, please lock this thread because this is getting uncivil.

the other option is people got tired of asking... Nike has a nice slogan that fits here

[HFTrader]

"Toxic behavior"? Come on. People are using a feature that Github made available for exactly this very ordinary use - for people to express consent or dissatisfaction. There is even emojis for love, to-the-moon, party, etc so we can choose to express ourselves.
The "Github ethics" is such a preposterous expression, perhaps because it's a made up one.
As @hediet well said "I'm probably the only one from our team who is subscribed". Then unsubscribe if you think this is spam. I believe that conversing is the way to solve issues, not banning of issuing a gag rule on the entire Github because you don't know where the unsubscribe button is.

[jason-koppel-avlino]

[J-Sorenson]

Hey, I saw that issue #198381 got a "VSCodeTriageBot" response and added to the backlog. How do we do that for old issues that existed before the TriageBot?
I know it's bad GitHub form, but I'm tempted to re-create this issue (linking to this one) so that we can ping the TriageBot with our votes. I think this vital feature has fallen into a black hole.

[vhnatyk]

so annoying :(

[Iaotle]

Hey, I saw that issue #198381 got a "VSCodeTriageBot" response and added to the backlog. How do we do that for old issues that existed before the TriageBot? I know it's bad GitHub form, but I'm tempted to re-create this issue (linking to this one) so that we can ping the TriageBot with our votes. I think this vital feature has fallen into a black hole.

Think you should just do it, the dev team will never get back to this.

[J-Sorenson]

Think you should just do it, the dev team will never get back to this.
Apparently so. Even if they mark it as duplicate, it would at least make them aware of it. Off we go, then....

[J-Sorenson]

After further searching, I don't think creating a second issue is going to help. The triage-bot only helps with labels (which this already has the correct labels) and whether to put this in the backlog (which has already happened). We just can't compete with 8,000 other requests. I'm going to install a proper diff editor (Meld) and use the "Meld extension."

For anyone monitoring this and wondering why we need to ignore all whitespace: imagine where a team applies an auto-formatter to clean up a project. You know, spaces around the equal sign, brace placement, spaces after commas, etc. In VS Code: the diff is a useless sea of red that fails to highlight any real differences. Honestly, I don't even know why a personal would ignore prefix whitespace (which are critical in many files), yet be hard-coded to highlight middle whitespace (almost always safe to ignore.

[aryanbhatt-0501]

How can I disable this marker besides 95 to not highlight the white spaces?

[Shakes1978]

Remove fortinet and unblock my websites