Diff editor: Differentiate unimportant differences

[KamasamaK]

I would like the ability to differentiate unimportant/minor differences in the diff editor. This is somewhat related to #43026, except this is not only about whitespace and ideally ignore should only be one of the ways this differentiation is used (e.g. different coloring). Obviously the semantics for what's "unimportant" is subjective and/or language-dependent. You might be able to use the language grammar (or new semantic API) to determine this in addition to some user configurability. Beyond Compare allows this differentiation based on a grammar with user configurability, and it's very useful.

The following are some examples of unimportant differences:

• Whitespace in a whitespace-insensitive language
• Case in a case-insensitive language
• Comments
• Strings?

[vscodebot[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our [documentation](https://aka.ms/vscode-issue-lifecycle). Happy Coding!

[vscodebot[bot]]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our [documentation](https://aka.ms/vscode-issue-lifecycle). Happy Coding!

[mikkorantalainen]

I think copying the feature that meld has on Linux would make a lot of sense. It allows defining multiple regular expression patterns for stuff to ignore in changes. The feature can be found in Edit - Preferences - Text Filteres. By default it has patterns for CVS/SVN keywords, C++ comments, C comments, All whitepace, etc. You can easily enable/disabled each of the defined patterns.

I usually have patterns such as "Leading whitespace only" (^[ \t\r\f\v]*), Trailing whitespace ([ \t\r\f\v]*$), Ignore numbers at the start of the line (^[0-9.]+), Git diff index line (^index [0-9a-f]+\.\.[0-9a-f]+) enabled because I often compare logs with timestamps at the start or big git diff outputs.

Doing it this way allows easily (we can expect developers to know regex syntax, right?) define your own rules for each use case. In addition, defining even default features using similar technique works as a nice example case how to come up with your own rules.

For really nice implementation also follow the style used in Meld: even if the change is ignored (not shown as changed block in navigation) the change is still rendered with slightly different background to make it easy to notice that some detail was actually changed even though it was ignored. This obviously requires color scheme that supports deleted and inserted text in addition to ignored deleted and ignored inserted text.

But definitely add toggles for each filter in some quick to access menu. Having to access global preferences settings to switch ignored parts for the current file is not a UI design pattern that should be copied.

I haven't checked how Meld actually implements this but I would assume it first computes the diff where each matched pattern is replaced with an empty string and after computing the whole diff, the lines are then rendered using the original data. This results in line matching to work as if the files actually didn't have any of the ignored parts but the actual diff rendering still shows the ignored differences, too. And as described above, the ignored differences are rendered with different style.

[yCodeTech]

Can we get an update when this will be implemented?

I am currently using the diff editor to view changes between different php.inis and there's a ton of http to https changes. This of course is very unimportant, and you can best believe that the diff overview ruler is red and green right the way down, thus I can't tell where the important line changes are. I wish to ignore these unimportant changes via regex.

A simple setting of diffEditor.ignoreRegex or similar would suffice. The setting could be an array of different regexes so the regex doesn't get too long on a one-liner.

[MohamedEssamAdawy]

I saw that it has been a long time since the last update, so let me raise the question again about this feature, when this will be implemented?

[yCodeTech]

@hediet ???