Detecting moves in the diff editor

[hediet]

No description provided.

[ElianCordoba]

I’m working in this problem too, although my approach is rather a 180 from myers algorithm and character by character diffing. Here is my work, still very WIP

[hediet]

@ElianCordoba thanks so much for reaching out!
Your approach looks very interesting! Unfortunately, VS Code does not have a solid infrastructure for ASTs, so the default diff algorithm implementation has to work without understanding of the syntax.

However, I'd like to explore the idea of allowing extensions to contribute (better/language-specific) diff algorithms.
Would you be interested in that?

I'll try to come up with some API ideas how extension contributed diff computers could look in the next couple of days.

Our default diff algorithm implementation initially will only support detecting very simple and straight forward moves that don't have additional changes. For now, the challenge of this issue is the UX.

[ElianCordoba]

Hi @hediet, thank you for taking the time to look at my work. I'm keen to contribute! I believe there is significant room for improvement in the field of text diffing.

Here are a few quick thoughts. I wanted my tool to be integrated within VSCode so you could check the diff without leaving the editor. There were two ways to do this, but neither convinced me:

• Use API to create a view: I found this was somewhat limited. The text decorating API wasn't flexible enough to implement a somewhat complex diff UI, which involves more than just marking additions and removals with green and red text. More on this bellow.
• Go the Iframe route: This could work but it would introduce unnecessary complexity. I'll revisit this option once my project matures, but I would prefer to use the API to leverage all the work you've put into the components.

My tool produces an array of changes, which are objects that holds the necessary infomation to, along side with the sources, render the change. These are a type, which can be deletion, addition, or move. The two ranges, and, in the case of moves a moveID.

When rendering, I take the original source code and locate the ranges to highlight them – additions in green, deletions in red. Moves affect both sources, which I color in blue.

While attempting to implement the move UX with the current API, I encountered a blocker, I couldn't figure out how to create a custom hoverable range, this was what I was trying to archive:

For these two ranges, my plan was to color them in blue and, when any of these are hovered over, find the corresponding code with the same ID (on the opposite side) and highlight that too.

Brief note on move UX

I realized that displaying code movements required some effort to make it clear where the code had moved. If the code only moved to the line below, it would be easy to spot because it would be immediately visible. However, if the code moved to the bottom of the file, you would need a way to link the before and after, and this becomes even more crucial when multiple moves are involved.
Ideally, when you highlight a move, you could see this in the minimap and click to select the move to keep it focused. These features are especially useful when the move is far off and you have to scrolling to view the new location.
A more ambitious idea was to draw some kind of arrow linking the two ranges. Here's an example from another project that uses arrows to visually link ranges.

This is the website of that project

[hediet]

Some example.

It would be nice to show this diff.

[hediet]

Work in progress update:

The border has to be tweaked and there should be a button to toggle alignment.

[hediet]

This feature is now available in the latest stable.

set "diffEditor.experimental.useVersion2": true and "diffEditor.experimental.showMoves": true to try it.

See #187432 for the remaining tasks.