Auto open Diff Editor when Refactor Preview is opened

Hi

I noticed that when we trigger Refactor Preview panel (eg. by using the vscode.workspace.applyEdit with WorkspaceEdits containing needsConfirmation), only the Refactor Preview panel is opened. To open the Diff Editor, users need to click on any of the edits in the panel.

Requirements:

• Should automatically open the Diff Editor with the first checked edit (not containing needsConfirmation = true).
• If no edits are checked, first FileElement should open letting the user select which changes to enable/preview.
• Moving out of the Diff Editor (e.g. clicking on a different file tab) created by the Refactor Preview panel, and reopening the Refactor Preview panel should reopen the Diff Editor. This would make the experience more consistent (Refactor Preview always opening the Diff).

Additonal Details:

• VS Code Version: 1.70.2
• OS Version: CromeOS 104.0.5112.83

part of the https://github.com/microsoft/vscode/issues/156886 proposal

tries to fix common problem as https://github.com/microsoft/vscode/issues/158408

[marrej]

Hi @daviddossett @jrieken , the main reason would be to cut down the click & improve the discoverability for new users (of Refactor Preview).

It seemed that the bottom panel is not fully understandable to users (what they should do with it/or expect from it) & some defaulted to ignoring the proposed fixes when provided with just the Refactor Preview, rather than following through. This then drives down the users will to interact with the extension & forces extensions to not try to use the Refactor Preview and strips good functionality - such as providing optional fixes, or not 100% confident fixes.

So by providing the detail along the driver, we want to increase the follow through & save users some clicks along the way.

Also, this would also be a novel interaction model, e.g opening a panel (driver) and an editor (detail) at the same time. For instance the search pane doesn’t open the first find match

I don’t think that these 2 usecases are exactly the same (search panel - refactor preview panel). As I understand it, most of the panels provide additional data into the current view. Allowing the users to trigger additional actions, such as opening a file that user might find helpful (via the search panel).

But refactor preview information might not be really helpful in the context of the actual open file. Mainly if the edits are not simple (e.g. rename x to y), but spanning through multiple lines, so the user can’t to easily grasp what the reactor is trying to do.

And since the user already wanted to Preview/apply the fixes it just makes sense to visualise exactly what they can apply.

Does that make sense?

[daviddossett]

I share the concern about opening two things at once. Is the desire to save the click? What else do you think this solves for @marrej?