Undo does not work with code actions or rename operations spanning multiple files

[leungbk]

With the TypeScript language server, if I move point to the function arguments here and execute the code action Convert parameters to destructured object, then attempting to M-x undo will undo the edit in that file, but will not undo the corresponding edits previously made in other files. Something similar happens when trying to undo lsp-rename operations.

I guess this should not be a surprise since undo is a buffer-local operation. But I wonder if it might be possible to implement some kind of alternate undo operation that can span multiple files affected by LS-induced changes.

[yyoncho]

In vscode they reverse the text edits so later they can undo the operation. I think that this is mainly due to the fact that vscode planform(or electron planform) does not provide the facilities that we have here in emacs(e. g. undo-amalgamate-change-group) but we could use this strategy to implement your suggestion.

It will be good to have a test suite for that as well since it has well-defined scenarios.

[leungbk]

I had assumed that since prepare-change-group handled multiple buffers via nconc, undo-amalgamate-change-group would as well. But that doesn't seem to be the case, at least not in the way I was expecting; each buffer appears to have a separate amalgamated group.

From quickly skimming the undo-related code in Emacs, I get the sense that the Emacs core would need to be patched to handle this kind of multi-buffer undo entry. undo uses only one buffer as its base buffer, and doesn't loop through multiple buffers as undo-amalgamate-change-group does.

Another concern brought up was:

I think what you want is not well-defined.  Say, after you inserted
something in A and something in B and make that operation a shared entry
in the undo history in both buffers, you change B and add something in
the middle of the inserted text so that it is split.  Or you do a
complicated query-replace in the inserted text in B.  You do other stuff
in A.  Now you undo in A until your special entry is reached.  What
would happen to B?  What would it mean to the undo history of A when
that corresponding change in B can't be undone so easily?

But I think there is a solution to this problem: simply block any further undo operations in A until reaching the corresponding point in B's undo stack.

[yyoncho]

But I think there is a solution to this problem: simply block any further undo
operations in A until reaching the corresponding point in B's undo stack.

So if you have applied multiple multibuffer changes you will have to find out
all involved buffers and undo them in the proper order and you will be blocked
if you want to undo changes in A? Or you will have the option to opt-out the
edits in other buffers? IMO this will be risky/tricky to implement and it might
cause losing undos. The alternative is to introduce M-x lsp-undo-workspace-edit which will work only if buffers haven't been touched.