Add initial support for LSP DidChangeWatchedFiles #7665
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pascalkuthe
requested changes
Jul 18, 2023
There was a problem hiding this comment.
This looks really promising, thanks for taking a stab at this! I will do a more thorough review later. One thing that I noticed immidietly us that I would prefer the filer handlr to be moved to helix-lsp. You can store the handle in the registry (that's stored on the editor so you can still keep most of the rest the same)
|
Also |
pascalkuthe
added
A-language-server
pascalkuthe
requested changes
Jul 18, 2023
pascalkuthe
reviewed
Jul 18, 2023
pascalkuthe
reviewed
Jul 18, 2023
pascalkuthe
previously approved these changes
Jul 18, 2023
pascalkuthe
removed
the
S-waiting-on-author
|
@the-mikedavis thanks for the review! I think I've addressed all feedback, but let me know if there's anything else you'd like me to change 🙂 |
the-mikedavis
approved these changes
Jul 21, 2023
pascalkuthe
approved these changes
Jul 21, 2023
mtoohey31
pushed a commit
to mtoohey31/helix
that referenced
this pull request
Jun 2, 2024
* Add initial support for LSP DidChangeWatchedFiles * Move file event Handler to helix-lsp * Simplify file event handling * Refactor file event handling * Block on future within LSP file event handler * Fully qualify uses of the file_event::Handler type * Rename ops field to options * Revert newline removal from helix-view/Cargo.toml * Ensure file event Handler is cleaned up when lsp client is shutdown
smortime
pushed a commit
to smortime/helix
that referenced
this pull request
Jul 10, 2024
* Add initial support for LSP DidChangeWatchedFiles * Move file event Handler to helix-lsp * Simplify file event handling * Refactor file event handling * Block on future within LSP file event handler * Fully qualify uses of the file_event::Handler type * Rename ops field to options * Revert newline removal from helix-view/Cargo.toml * Ensure file event Handler is cleaned up when lsp client is shutdown
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: #1125 (comment)
This PR implements initial support for LSP DidChangeWatchedFiles by forwarding a notification for all file writes or reloads to any LSP that has registered with a matching glob. This work will enable LSPs to respond accordingly to changes made to any metadata files (e.g.
Cargo.toml) that they have registered for notifications on. For now it can only forward notifications for changes that occur within Helix, however this code can continue to be used when a proper file watcher is added at some point in the future.For the implementation, a new file event
Handlerstruct spawns a dedicated tokio task to listen for any registrations/unregistrations by LSPs as well as any file change events. Since theEditorstruct owns thehelix-lsp::Registryinstance, I saw a few potential designs for theHandlerto be able to access LSP clients. Ultimately, I chose to pass theHandleraWeakreference to the LSP clients as they register for file watching. This is done so that theHandlercan have direct access to the client without preventing the client from being dropped if it is closed and isn't properly notified. Alternatives could include synchronizing references to clients between theEditorandHandler, synchronizing access to the LSP clients, or notifying theEditorof file change notifications that need to be sent to LSPs via a new channel. My opinion is that all of those alternatives seem more complex or bug-prone.There are certainly optimizations that can be made (e.g. batching file changes) but I think those can be added in future PRs, as necessary.
I've tested these changes successfully with the rust-analyzer and gopls LSPs on both macos and Linux. Changes to the
Cargo.tomlof a crate are immediately recognized by rust-analyzer, instead of having to restart the LSP.Thanks!