Suggestion: collapse unchanged regions in diff

[factormystic]

When viewing a diff (2 pane or inline) it would be useful to collapse the unchanged lines. This helps focus in on just the changes, especially when the changes are few an spread out.

[rijk]

This is something I can't live without, the collapsing along with the inline Stage/Discard buttons makes it so much easier to keep commits tidy:

This screenshot is from GitX — still by far my favorite Git UI. I have tried literally all the extensions in VS Code, but none comes even close. I think this is something the core editor has to provide.

[ToMakeSense]

related to #87944

[sdegutis]

This is one of the main things Magit gives me and Magit is the only reason I use Emacs anymore, please add this feature.

[ADTC]

@jakedowns Try using the "vscode-diff" extension. It doesn't solve the problem in this issue. However it generates and opens the output of git diff in VS Code.

Do note that if you're on Windows, you need to modify the JS file of the extension to fix the problem described in huytd/vscode-diff#1

And if you want a nicer view, you can add the "Diff Viewer" extension. You'll have to make the same change above (to "vscode-diff" regardless of environment) to change to the diff extension. Then right-click the editor tab and click Reopen Editor With... to choose Diff Editor.

[archon810]

It is a shame that git diff provides better overview of changes than VS Code. 👎🏻

Not just git diff. Github itself, Bitbucket, Beyond Compare, pretty much all code diff tools do this.

[ThomasGHenry]

I left VS Code for WebStorm a few years ago. I thought I might come back, but I keep bumping into things like this.

[jordyvandomselaar]

Hi @archon810 nice bumping in to you 😁

Agree, for now I just use the "jump to next change" button to work around this, but the current diff viewer makes for a cluttered experience.

[antichris]

Another idea (ignore the lagging and flickering, it's a prototype to evaluate the idea):

(Click to reveal the preview)

I kind of like this UI. I think the active zones of the divider should be not just the very edges, but rather the top and bottom halves. Dragging could gradually reveal lines like in the prototype, clicking should reveal a fixed number of additional lines (5, 10, 15, or, optimally, configurable). A tooltip could help with discoverability. The exact appearance of the divider is debatable though, I would prefer a straight edge with a hint of shadow, similar to how the sticky scroll feature is done.

I think the number of context lines shown initially should have a global setting (user, workspace), that can be adjusted per file (ideally, remembered, but can be reset back to the configured value).

And there should be an action (or two) to collapse/expand all unchanged regions in the current diff view.

[ADTC]

The exact appearance of the divider is debatable though, I would prefer a straight edge with a hint of shadow, similar to how the sticky scroll feature is done.

To me there's no debate. The wavy line looks cartoonish in an otherwise professional user interface.

Is no one else against it? 😅

[antichris]

Is no one else against it?

I wouldn't say I'm terribly happy with the way it looks now. But I'm also one of those who still use the official Tcl/Tk git gui in 2023, so it may not be a very unreasonable guess to say that I don't really give two shits about pretty graphics when it comes down to tools. As long as it's not so bad that it gets in the way of what one is trying to do.

I just noticed that the draggable prototype seems to snap to whole lines. I may be in minority, but I think it should only snap when the exact number of context lines is changed (e.g., on a click to show more lines). Dragging should be smooth, even if it could end up cutting off a part of the line when let go. UI components snapping out and away from under the cursor, on the other hand, do make for a very lousy UX — one that can get in the way of what someone is trying to do.

Ooh! And yet another idea: instead of having to drag, scroll and drag again (maybe, a few more times), clicking the active zone could hold it fixed in place under the cursor, scrolling the rest of the view with the revealed context lines instead. This way the user could comfortably add huge swaths of context lines by simply clicking the same spot repeatedly.

[hediet]

Here another idea:

The drag&drop idea can be implemented in the future on top of this design (which is technically quite involved to do it properly, so it probably won't be included in the initial release of the new diff editor)

This prototype also shows how context could be included, similar to what GitHub does (current method/class).
Initially I thought the header lines could just stay visible (surrounded by the break-spacer), but that adds too much noise.

[ADTC]

Loving the new clean straight-edged bar. Perfectly blends in with the UI while standing out just enough to notice without distracting. Thank you so much!

I think I'm also in agreement with the new version, to click the border. Could you possibly make the click target larger though, at least 5 pixels (inside the bar at the border), even if the border itself is only 1-2 px?

Then I have one more suggestion, optional but for consideration: instead of the standard tooltip that opens after a delay, consider replacing the text "32 hidden lines | 🎏 DiffEditorWidget2" with "Show more lines above/below" and "Show all lines" immediately when hovering the respective click target, then return it back to the original text when mouse is moved away or when "Show more lines above/below" is clicked (updating the number of lines).

Or maybe the tooltips can appear faster or a custom popup tip can be used which appears immediately and is also themed.

[antichris]

Could you possibly make the click target larger though, at least 5 pixels (inside the bar at the border), even if the border itself is only 1-2 px?

I still stand behind the idea that the entire half of the bar should be the clickable active zone. Here's a quick mockup:

In this case it may also be worth considering making the gutter with the "Show all" button not covered by the active zones. (Expand for a picture.)

I think it makes sense that the active zone spans both sides of the diff view, as interacting to add context lines on one side of the diff view should do precisely the same on the other.

[hansu]

Here another idea:

No, please don't do that. It's very un-intuitive that there are borders which are suddenly clickable. Further it needs precise pointing of the mouse to hit that thin line.

I think reserving the space of two lines with one button on top of the other is totally fine.
Keep in mind that you should compare the space actually needed by the bar to the space of the lines that are collapsed and not thinking that it is an additional bar that just wastes you space.

[ADTC]

@hediet I'd say that hansu has a good point. Using a border to do something other than changing the width/height of a section is not normally expected. It will be a brand new behavior to learn from a UI/UX perspective - something we should avoid adding unless we're introducing a groundbreaking new UI behavior with many potential use cases.

It's OK for a collapsed code bar to take up about 1.75 to 2.0 lines of height, (especially now that you've gotten rid of the wavy edge which took up too much space). I think the GitHub style is good enough, which shows expand up/expand down buttons stacked. Maybe holding Control or Option(Alt) could change the split buttons to a single Show All button (which is also normally shown when there's not enough lines to warrant the split buttons).

We should also have a separate option somewhere to expand and collapse all sections of unchanged regions in the file. It's something GitHub has in the file header (because the diff page has many files in it). [Note: Although GitHub remembers the individually expanded sections and keeps them expanded when we collapse all sections across the whole file, this isn't strictly necessary.]

Please give it a try, and show us a demo when you can. Thank you.

[ADTC]

GitHub screenshot for reference

(from this pull request)

[ADTC]

There's also the use of a different background color and a subtle border in GitHub for the expanded parts of the code, which is also nice to have, as it distinguishes the unchanged code (outside context limit) from the changed code and the limited context around it.

Screenshot

[hediet]

Closing, as this has been implemented now in the new diff editor.

You can try it out (restart VS Code after changing these settings):

"diffEditor.experimental.useVersion2": true,
"diffEditor.experimental.collapseUnchangedRegions": true,

The new diff editor will replace the old diff editor soon.

[rijk]

Awesome!! 🕺

[ADTC]

You can try it out (restart VS Code after changing these settings):

Which version is the minimum? Thank you for making this happen btw.

[hansu]

Great!
But feels still weird with the arrow directions (contrary to GitHub) especially in this case:

[hansu]

I further wonder if it makes sense to collapse unchanged regions when having only one change.
The diff editor V1 scrolls automatically to the change so there is no real need for collapsing and it might be more convenient to show the whole file in this case.

[rijk]

I don't agree with that. Collapsing unchanged code is always a good thing to reduce mental tax and ensure you've seen all the changes. Regardless if 1 or multiple changes.

[hediet]

@hansu this is an old version. Please try the latest insiders!

[hansu]

I don't agree with that. Collapsing unchanged code is always a good thing to reduce mental tax and ensure you've seen all the changes. Regardless if 1 or multiple changes.

Maybe this comparison makes it a bit more clear:

Diff editor v1:

Diff editor v2:

[ADTC]

Why is almost everyone sticking with side-by-side view? 😂😂😂 I find inline view to be much better. Full 100% width, and no redundancy of seeing the same unchanged line twice. I hope this feature works well with inline view as I haven't seen any screenshot of that yet.

PS: There is one exception where I have side-by-side view and that is in Beyond Compare because this paid software really goes beyond just comparing chunks of change to actually aligning lines by a computed score of similarity. I find this very useful for certain types of comparisons. I haven't seen any other side-by-side diff tool do this, and that's why I generally opt for inline view. Without the line similarity matching, any side-by-side view doesn't offer an advantage over inline view, and it's even disadvantaged IMHO due to the narrow width and redundancy.

[hansu]

@hansu this is an old version. Please try the latest insiders!

Oh sorry, I didn't check that.
But the current version is even more unconvenient in this case:

Also a bit weird that the text goes first down and then up. I hope you get back to the buttons you had before :)

[hediet]

Also a bit weird that the text goes first down and then up. I hope you get back to the buttons you had before :)

That is a bug. These sashes are actually clickable and do the same as the button!

[hansu]

That is a bug. These sashes are actually clickable and do the same as the button!

Oh, I didn't expect that.

[rijk]

To me, it's perfect! 😍 Great work @hediet

[hansu]

Really great how it looks now, really helpful 👍

I discovered a little thing, see: #187820

[KayLeung]

Finally!!! This landed on July 2023 (version 1.81) (experimental)!!!!!

Only one problem, the changed view has inline hints. It increases the noise to compare 2 sides.

[ADTC]

Could anyone please share screenshots / videos of how the inline (unified) diff looks like? Thank you.

I'm afraid to switch because I feel like I'll be disappointed. All the talk so far have been about perfecting the side-by-side, and I only use inline diff. :)

[yume-chan]

There are some issues with the inline view:

With "editor.lineNumbers": "off", there are two collapse buttons after expanding collapsed area:

(I think it doesn't need two even when "editor.lineNumbers": "on", as it only have one "Show All" button)

---

Switching editor.lineNumbers on/off, the layout is broken, need to resize the editor to let it re-render:

Switch from "off" to "on":

(Only shows one column of line numbers)

From "on" to "off":

---

The left line number column highlights the last selected line in the side-by-side view:

---

Version:

Version: 1.82.0-insider
Commit: e8b1e2bea88d34a813405a176148dd9fd17cbb1f
Date: 2023-08-03T17:09:22.928Z
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.82.0-insider Chrome/108.0.5359.215 Electron/22.3.18 Safari/537.36