WorkspaceEdit for files isn't atomic/undoable

[isidorn]

Refs: #52800

I could not find anywhere specified that if one workspace edit fails, all consective edits will not even be attempted.
If feel like this is good behavior but expect some explanation in our vscode.d.ts comments.

[joaomoreno]

I also wonder if we should specify the reason for returning false. How can an extension react correctly to a false result?

[jrieken]

Well, there is this: "the editor implements an 'all-or-nothing'-strategy," which is arguably written towards textual edits (for historical reasons) but the idea is the same. The problem is more the lack of composite undo and the lack of undoable file operations.

[joaomoreno]

@jrieken Wait, I don't think that's true. all or nothing means that either all run or none run. With these file system changes, you can have some run and others don't, since there's no rollback. The current strategy is more like run until failure.

[jrieken]

The problem is more the lack of composite undo and the lack of undoable file operations.

Yeah, I think it's still a desirable goal ;-)

[joaomoreno]

It is... but aren't the docs wrong if they say it's all or nothing?

[jrieken]

yeah, I was hoping we can fix it once this goes to stable API... I'll reopen and see what I can do there

[jrieken]

@bpasero Is it in reach to undo a file operation? Anything like that supported or thought of in the file/textfile service?

[bpasero]

@jrieken the IFileService is probably not a good place for undo/redo, the ITextFileService might be a good fit, but obviously needs some infrastructure to implement this. I think the challenge is to undo delete operations, whereas move and create (once added) are probably easier to get right.

[aeschli]

Slightly different topic, but also to be improved in the vscode.d.ts comment:

Note that all changes are applied in the same order in which

• they have been added and that invalid sequences like 'delete file a' -> 'insert text in
• file a' causes failure of the operation.

For text edits applied at the same offset, the rule is:
If multiple inserts are made with the same position, these strings appear in the resulting text in the order the 'insert' was made.