feat(diffViewEditor): Add autofocus feature to preserve focus on edit…

[felixAnhalt]

This pull request aims to be a very simple implementation to fix the issue #2122.
Closes #2122 .
Diff Views now get opened in the ViewColumn ViewColumn.Beside and the edited file is not shown anymore after a successfull edit. Furthermore, only the diff view is being opened instead of the actual file and the diff view as well.
A more sophisticated approach respecting customizations in regards to editor can be found here.

This is how an iteration with multiple file edits looks like.

Screen.Recording.2025-07-14.at.10.41.07.1.mov

Copilot Summary:

This pull request refines the DiffViewProvider functionality in the VS Code extension by improving focus handling, normalizing content editing behavior, and updating test cases. The changes ensure better user experience during file editing and enhance code reliability.

Focus Handling Improvements:

• Removed logic that placed the cursor at the beginning of the diff editor to avoid interfering with the stream animation, ensuring focus remains on the actively edited file.
• Updated the file opening logic to use TextDocumentShowOptions with ViewColumn.Beside to preserve focus while executing the diff command.

Content Normalization Enhancements:

• Added trimEnd to normalize edited and new content, ensuring consistent end-of-line handling without trailing whitespace.

Test Case Updates:

• Modified test cases to reflect the updated focus preservation logic and verify the correct execution order of commands.
• Adjusted mock objects in tests to include the scheme and fileName properties for accurate simulation of the DiffViewProvider behavior. [1] [2] [3]

Dependency Updates:

• Imported TextDocumentShowOptions and ViewColumn from vscode to support the new focus handling logic.

---

Important

Improves focus handling and content normalization in DiffViewProvider, updating tests accordingly.

• Focus Handling:
  • Removed cursor placement logic in DiffViewProvider to avoid focus interference.
  • Updated to use TextDocumentShowOptions with ViewColumn.Beside for diff command.
• Content Normalization:
  • Added trimEnd to edited and new content in DiffViewProvider.
• Tests:
  • Updated tests in DiffViewProvider.spec.ts to verify focus preservation and command execution order.
  • Adjusted mock objects to include scheme and fileName properties.

^{This description was created by for 1f6d6d8. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Hey @felixAnhalt Thank you for your work on this! I was wondering if we should open the edited files after a successful edit. The main concern is that if no files are opened, the user might have trouble knowing which files were created or changed. What do you think?

[felixAnhalt]

Hey @daniel-lxs

I personally feel like my workflow is more fluent if it doesn't open the file after each edit.
Because if multiple files are being edited in one task it then takes focus again.
Generally I also think to see which files were created or changed people would usually look into the source control tab to see diffs etc after being done. But that's just an assumption.
Secondly, if people are not autopiloting it, then you'd always see the changes in the diff anyway if you want to.

If you still want to show all files that were created or changed, roo would have to collect the information of all files successfully edited at a higher level than currently. This has to happen because the DiffViewProvider gets reset after each iteration on a file.
We could do so at either task level instead of inside the editor or statically inside the editor or something else.
We could also track that data inside the editor itself and add a separate reset function which is executed after the task is done.
And then show them after the task is complete and take focus with doing that.

I could do that as well.

We could also add settings to control that behavior but I would like to hold that off for future endavours.

[felixAnhalt]

This is how it would look like if we show all touched documents after the task is finished.

Screen.Recording.2025-07-16.at.20.03.42.1.mov

[felixAnhalt]

any uodate on preference @daniel-lxs ?

[daniel-lxs]

Hey @felixAnhalt Sorry for the delay. One important point: VSCode only applies diagnostics to open files. This means Roo Code can’t access issues introduced in a file unless that file has been opened at least once. If a file remains closed, its diagnostics simply aren't available.

[felixAnhalt]

@daniel-lxs

I dug a little bit deeper.
the line vscode.commands.executeCommand("vscode.diff", ...) triggers diagnostics for a file as well.
I moved the setting of pre-diagnostics and the getting of post-diagnostics to their respective places to only activate after a diff was opened and before the diff gets closed.
This way we make certain to still be able to get diagnostics even though a file is not opened.

Anyways, regarding my initial question.
What would you prefer?

• A: Not opening any files at the end of the editing process (does not steal focus any time)
• B: Opening all files at the same time when editing is done (would steal focus after the task is done)
• C: Opening a file, after the diff is done (would steal focus each time an edit is through)

[daniel-lxs]

Hey @felixAnhalt I managed to pull this off with Roomote's help #6214

It uses the vscode.workspace.openTextDocument() method to load the diagnostics without opening the file, do you think we can build on top of that new experimental setting?

[felixAnhalt]

Finally vscode did something to support that!
I actually tried vscode.workspace.openTextDocument() yesterday but didn't see the technically opened document inside the diagnostics array while inspecting in the debugger, but maybe I missed some implementation detail (this one here probably).

So by look at what mrubens said I assume that your preffered option is A (don't show anything afterwards) @daniel-lxs ?

What mrubens proposes is essentially #6010 after this current issue #2122 is solved with option A, correct?

[daniel-lxs]

Yeah @felixAnhalt The main concern was the diagnostics, but that is solved.

Are there any feature you want to add to what we have now from this PR? or should this be closed?

[felixAnhalt]

@daniel-lxs This is everything I wanted to achieve with #2955 and this pull request here.
This might have implications for #6217 (file-based editing or "stealth mode") and the corrsponding issue #6001 as well.

I think your (or roomote's solution) solves all of these things and they might be closed if you don't see any gain for the product from these things.

It might make sense to have a look at #6010 if the added settings is ready to go into production and out of "experimental".

[daniel-lxs]

Gotcha, Closing this one for now