Support external diff algorithms in internal diff editor

[pvspain]

Reopening closed feature request #30694

Openness, extensibility and customisability are the features that keep me coming back to VSCode. Being built upon an OSS core (Electron) was strong evidence of a change of culture at Microsoft.

In that spirit, would you please reconsider the original request from @myfairsyer. Different diffing algorithms produce significantly different results and are suited to different purposes. There is no one-size-fits-all solution.

Paraphrasing @myfairsyer, please consider abstracting the diff functionality to allow different hunk-list providers. Respecting the algorithm set in Git configuration would be an ideal baseline.

As another example, BeyondCompare allows significant customisation, including 2 of the 4 algorithms offered by Git.

[ksze]

Yep, I agree that VS code should support external diff tools with their known algorithms.

[Hermholtz]

I'm missing Git's "patience" algo.

In my opinion there's a place for API and extensibility here. We could have various diff algorithms available as extensions, in addition to a good set provided right inside VS Code.

[vscodebot]

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.

Happy Coding!

[vscodebot]

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

Happy Coding!

[ghost]

Any update here?

Internal diff algorithm sometimes gives poorly visual results.
I wish I could use patience diff algorithm in vscode diff editor.

[daevski]

Yeah, this is ridiculous; notepad++ compare on the left, vscode compare on the right.

[bersbersbers]

I would like to reference feature request #145068 here (disclaimer: it is taking votes, and I am the author) which may or may not make sense considering when defining an interface for alternative diff algorithms or diff extensions (in which case it might also be implemented independent of the diff algorithm as some kind of post-processing.)

In essence, I propose another change category (in addition to the current ones, which are green = line added and red = line removed). This new category (let's call it gray) shall represent lines which have no other change but being commented out or in (using language-specific grammar rules) with respect to the reference lines, allowing to overscroll them more easily because color and font style encode the only change (enabling/disabling the line).

[0dB]

this is ridiculous; notepad++ compare on the left, vscode compare on the right.

Highlighting inside a line is an Ediff feature. Diff just looks for changed lines, no matter what the algorithm is. The difference between the diff algorithms (the original diff, myers, minimal, patience, histogram) is how the lines between two files are ligned up. So it seems Ediff is being used on the left by notepad++ and not on the right. In Emacs for example you can activate Ediff for displaying a diff / diff3 output (and this is independent from the diff algorithm).

[pawk3k]

Do you have any updates on that? Do you have any plans on adding support for external diff tools? 🤔 . I'm thinking more about using difftasctic as a diff tool for vs code.
I'm not the only one here :
https://news.ycombinator.com/item?id=30841244.
https://stackoverflow.com/questions/73671245/how-to-change-the-diff-tool-used-by-vscode-for-git
Also, if anyone knows if it's possible right now, how can we achieve that?

[maffinyep]

up