search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.39k stars 28.94k forks source link

Auto open Diff Editor when Refactor Preview is opened #159327

Open marrej opened 2 years ago

marrej commented 2 years ago

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:

Additonal Details:

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

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

vscodenpa commented 2 years ago

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

dynamicwebpaige commented 2 years ago

Excited to see this proposed change and PR! Just upvoted. 🙂

vscodenpa commented 2 years ago

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

jrieken commented 2 years ago

Should automatically open the Diff Editor with the first checked edit (not containing needsConfirmation = true).

I see how that saves users a single click but I am afraid that it causes distraction. The important/complete information is in the preview panel and the diff editor is just one aspect of the refactoring. Attention should be drawn to complete list and to the place where "Accept" and "Discard" buttons are.

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

/cc @daviddossett for input and consideration

daviddossett commented 2 years ago

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?

marrej commented 2 years ago

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?