-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: Revert the changes from the last refactor. #70610
Comments
The applyWorkspaceEdit operation has a label field, documented thus:
This seems to imply that it is the client's responsibility to provide an undo operation at a higher level of operation than the individual DocumentChanges. Gopls does not set this field, and it probably should. I did a quick test with it set to an arbitrary value and found that VS Code implements high-level undo (but doesn't mention the label in the UI, so it may be irrelevant), and Emacs+eglot does not; I don't know to what extent this feature is supported by other clients. |
This can be achieved by iShot_2024-11-30_06.45.36.mp4 |
This would probably be surprisingly tricky to implement. From gopls' perspective, we just ask the client to apply an edit (or return the edit from an operation), and then may or may not receive subsequent didChange notifications. Each of these notifications is for a different file, and so for edits spanning multiple files there's no way to know when all changes are done. We could theoretically just collect edits following a change, and as long as they match edits we recently sent, hold open a code action to revert the edits. Even that is pretty hacky though, and furthermore there's no reason that clients have to send us exactly the edits we sent: there are many different ways to represent the same logical edit. So we'd have to apply those edits and then rederive our edit representation to see if it matches. So we'd have to do all that work, and we'd have to be really accurate in order to make this feature reliable. And if the feature misbehaved, it would be very confusing for our users. The reason this is all so awkward is this: the LSP is designed around the principle that clients control state and lifecycles of operations. Exposing a 'revert' feature from gopls is in direct opposition to this principle. As much as I'd appreciate such a feature. I don't think we can reasonable do this. This must be implemented by clients. |
gopls version
golang.org/x/tools/gopls v0.16.2
golang.org/x/tools/gopls@v0.16.2 h1:K1z03MlikHfaMTtG01cUeL5FAOTJnITuNe0TWOcg8tM=
github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW
6Y=
golang.org/x/mod@v0.20.0 h1:utOm6MM3R3dnawAiJgn0y+xvuYRsm1RKM/4giyfDgV0=
golang.org/x/sync@v0.8.0 h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=
golang.org/x/telemetry@v0.0.0-20240829154258-f29ab539cc98 h1:Wm3cG5X6sZ0RSVRc/H1/sciC4AT6HAKgLCSH2lbpR/c=
golang.org/x/text@v0.16.0 h1:a94ExnEXNtEwYLGJSIUxnWoxoRz/ZcCsV63ROupILh4=
golang.org/x/tools@v0.22.1-0.20240829175637-39126e24d653 h1:6bJEg2w2kUHWlfdJaESYsmNfI1LKAZQi6zCa7LUn7eI=
golang.org/x/vuln@v1.0.4 h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
honnef.co/go/tools@v0.4.7 h1:9MDAWxMoSnB6QoSqiVr7P5mtkT9pOc1kSxchzPCnqJs=
mvdan.cc/gofumpt@v0.6.0 h1:G3QvahNDmpD+Aek/bNOLrFR2XC6ZAdo62dZu65gmwGo=
mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.23.1
go env
What did you do?
When the parameter b is removed, I want to revert.
Change multiple files, I need to switch to multiple files to undo.
What did you see happen?
No "CodeAction".
What did you expect to see?
Revert the last change.
Editor and settings
No response
Logs
No response
The text was updated successfully, but these errors were encountered: