fix(diff-editor)-performance

[chezsmithy]

Description

When the diff editor was running in vscode it was frustrating that the progress would slowly start from the top of the file and make it's way to the bottom. Sometimes it felt like nothing was happening until the change cursor came into view.

I added code to change the focus in the editor depending on where the current edit is occuring. Interestingly this had the side effect of speeding the whole process up imensely for me. I'm curious if others see the same difference.

I also added code to push the viewport to the top of the file after all the edits are complete to give a visual indication that the process is done. Note, it might be better to focus the editor at the first diff but I didn't see an easy way to determine where that was without a more significant change.

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created
• The relevant tests, if any, have been updated or created

Screenshots

[ For visual changes, include screenshots. Screen recordings are particularly helpful, and appreciated! ]

Testing instructions

1. Ask for logging to be added to @test.js
2. Observe that after a bit of a wait the editing to the test.js file starts
3. Note that the current line displayed in the editor window follows the changes being made.
4. Observe the speed of applying those edits seems to be significantly improved. (side effect?)

---

Summary by mrge

Improved the diff editor in VS Code so the viewport follows edits as they happen, making progress clearer and speeding up the editing process.

• UI Improvements
  • The editor now scrolls to each change as it is applied.
  • After all edits, the view returns to the top of the file to show completion.

[netlify]

✅ Deploy Preview for continuedev canceled.

Name	Link
🔨 Latest commit	961d0c4
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/681e78184ce8110008431a0f

[Patrick-Erichsen]

Wow, very simple addition but makes a huge difference! I tested this with Edit to see how it would behave on a single-range change (i.e. not a full file) and it also worked great, the jump-to-first-line-of-range logic is quite nice.

Thanks for the attention to detail here!

[chezsmithy]

@Patrick-Erichsen thanks! I was a bit shocked by the performance change. I wonder if it has something to do with making changes in the editor outside the currently displayed viewport? None the less it's a quick win.

[Patrick-Erichsen]

Let's keep an eye out for user feedback on this one. Since this effectively forces the viewport to follow along with edits it prevents users from pausing to read the code as it's streamed in.

[HQ1363]

Jetbrains, it's also slow. Is there room for optimization?