Support preview a WorkspaceEdit

[testforstephen]

For many refactoring actions (e.g. Move Java file, Rename Java class/package name), it possibly involves updating multiple files, which is especially true for refactoring some big projects. If the VS Code supports preview the changes of a refactoring WorkspaceEdit before applying, this will help the user discover the potential refactor effects in advance and decide whether to continue the operation.

Generally a WorkspaceEdit contains text edits (Insert, Delete) and resource edits (CreateFile, DeleteFile, RenameFile), they are naturally diffs, and very suitable for preview.

[jrieken]

I have merged #88428 which implements a first version of this: 👇

What's implemented

• Refactor preview shows all changes - currently only grouped by file
• Show diff view for each change
• Check/Uncheck individual changes or all changes per file
• Detect concurrent file changes
• Restore previous view state when accepting/discarding changes

What's still missing and/or unclear

• There is no API yet to allow extension to suggest that a preview is necessary, for now the rename box allows the user to chose
• This is currently only enabled for rename as the UX flow for code actions isn't clear yet
• Changes are only grouped by files, e.g there is no support to group by change type like "change in a comment" etc. This will also require new API.
• Changes are "checked" by default. This will require new API
• Show a summary like "Changes for renaming 'foo'", likely also requires new API

[jrieken]

/cc @bobbrow

Wrt to knowing if a preview for rename is needed or not: Does C/CPP know this during the prepareRename-call? We could extend its return-type so that it can signal if a preview is required or optional

[bobbrow]

Very cool. @Colengms should be able to help you answer your question. I don't see an implementation of prepareRename currently.

[Colengms]

Hi @jrieken . Do you mean provideRenameEdits? My understanding is that prepareRename is optional, and used to validate whether the target position of the rename is valid.

Currently, we are using only provideRenameEdits. Could you clarify why we might want to use prepareRename as well?

In our current implementation, if all of the matches found are known to be associated with the selected symbol, we return results from provideRenameEdits immediately. Otherwise, we present UI to allow the user to categorically and individually select what to rename (to opt into things such as matches in comments), and reissue the rename in order to complete it with the selected results.

Are you suggesting we leverage preview instead of our own UI, and make preview required in the scenarios in which we would otherwise have presented our own UI? If so, yes, we would need a way to return that preview is required, but wouldn't that be when returning from provideRenameEdits, as we would discover whether preview is required in the process of scanning for all candidate locations?