Refactor Preview better feedback on user actions

[marrej]

At the moment Refactor Preview (triggered by vscode.workspace.applyEdit) does not provide any feedback to the caller with has happened inside. It always responds back with true, which makes it hard for the extension to assess whether user applied/discarded changes without additional diffing mechanisms. Therefore it would be really helpful to get a response back from the Preview which would already contain data about the event that happened (such as Apply/Discard/Open) as well as the actual edits that were applied.

There are 2 ways I see this problem can be solved.

Providing a lower granularity, where the whole WorkspaceEdit would be only able to respond to one single requestor.

Providing a high granularity visibility for any of the provided edits. Which might be useful if an extension wants to get different feedback for slices of the input data (e.g. when multiple teams use a single extension to provide fixes which can be merged together to provide a better UX).

Both of these approaches would expect an input data (feedback) in form of

{
  commandId: string,
  additionalArgs: any[]
}

And return data in the form of

{
  event: APPLY|DISCARD|PREVIEW_OPEN,
  edits: { // used on apply only, to signal which edits were applied
    Checked: boolean,
    Range: vscode.Range,
    Content: string,
    filePath: string,
    needsConfirmation: boolean
  } 
  additionalArgs: any[]
}

The flow for the approaches would be:

The first approach would count on extending the vscode.workspace.applyEdit with a second property, such as options, which could be populated with additional parameters such as feedback. This data would be passed to the bulkEditService.apply via IBulkEditOptions (which would have to be extended as well with this property). Then on opening the Refactor Preview PREVIEW_OPEN event with additional arguments would be sent. Once a user clicks on Apply or Discard the respective event would be sent. When Apply is clicked, then as well all the edits should be compacted to the format specified above to signal which edits were checked/non checked.

The second approach would extend the WorkspaceEditEntryMetadata with feedback property. The main difference compared to the first option is that all the commandIds would have to be extracted from the edits & the respective edits sent to their predefined commandIds. This as well allows then to gather feedback for only a specific subset of the provided data.

The second approach does come with a big possible caveat and that is that data would be redundantly existing in all the edits. As well as some edits could have different additional arguments, meaning that we could end up sending data to the same command Multiple times with different arguments. Although if this could be mitigated by throwing an error if one commandId would contain multiple additionalArguments

VS Code Version: 1.71.2 OS Version: CromeOS 104.0.5112.83