-
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: watch file changes on disk #31553
Comments
Does this not contradict what you said the other day in terms of this being the editor's responsibility? |
No, workspace/didChangeWatchedFile, s is the mechanism by which the server can ask the client to tell it when a file changes, which makes it the editors responsibility |
Got you. I misconstrued the title of the issue: it's actually that |
Just jotting down a couple of notes/questions:
|
|
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
For now use textDocument/didOpen and textDocument/didChange to deal with generated files changing, whilst we await a proper implementation in gopls via golang/go#31553.
To update this thread, I am planning to begin work on implementing workspace/didChangeWatchedFile in gopls |
Is this one available or does @suzmue still have dibs? |
I'm sorry, I mistakenly added the Suggested label here. I believe @suzmue is still working on this. |
@stamblerre what's the latest status on file watching support in I'm wondering if we can remove the workarounds we have in Thanks |
It should be coming soon, but not in time for the next |
Not sure if it was intentional, but the options refactoring ended up enabling file watching be default in gopls. |
Yes, that actually was (I know it doesn't make much sense since it doesn't work yet). I just want to eliminate that option altogether, since I think it will become very difficult to investigate issues if we have multiple modes of updating files. I'm aiming to get the final few CLs out in the coming days. |
Change https://golang.org/cl/214277 mentions this issue: |
This is the beginning of the CLs to refactor the file watching code with the normal text synchronization code. This hasn't yet been tested other than with some minimal local testing, so follow-up CLs will be needed. Updates golang/go#31553 Change-Id: Id081ecc59dd2903057164171bd95f0dc07baa5f1 Reviewed-on: https://go-review.googlesource.com/c/tools/+/214277 Run-TryBot: Rebecca Stambler <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
File watching now works with |
Change https://golang.org/cl/215902 mentions this issue: |
This is the first in a series of changes to batch file changes. First, we have to support invalidating a snaphot with multiple files. Updates golang/go#31553 Change-Id: I7cd83d9280e3274549a72393bb9010c47eb5dd1e Reviewed-on: https://go-review.googlesource.com/c/tools/+/215902 Run-TryBot: Rebecca Stambler <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
Change https://golang.org/cl/215906 mentions this issue: |
Change https://golang.org/cl/215907 mentions this issue: |
Caught a number of unused parameters along the way. Hopefully we can eliminate the containsFileSave boolean soon, since it's a bit annoying to have to send that through. Updates golang/go#31553. Change-Id: I94319d902d329c84cb1c0676322ac04541ad53a0 Reviewed-on: https://go-review.googlesource.com/c/tools/+/215906 Run-TryBot: Rebecca Stambler <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
We don't yet propagate these batched changes in text_synchronization.go, but this is the next step in moving towards a batched approach. Updates golang/go#31553 Change-Id: Id6496af9d5422cc50ccb995f81c71ec1886f965a Reviewed-on: https://go-review.googlesource.com/c/tools/+/215907 Run-TryBot: Rebecca Stambler <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
Change https://golang.org/cl/215908 mentions this issue: |
We cache a lot of information like the AST and typechecking data per file.
If someone changes a file outside the editor, often by doing things with their vcs (update/branch switch is the most common thing mentioned) we currently do not attempt to re-build that information unless it is invalidated by an editor change.
We should be using the LSP handling for workspace/didChangeWatchedFiles to watch all the files we are caching and invalidating them.
It is not clear if we can/should do anything if the client does not support this capability.
The text was updated successfully, but these errors were encountered: