-
-
Notifications
You must be signed in to change notification settings - Fork 540
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
feat(editor): Support nested configs #9743
feat(editor): Support nested configs #9743
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
CodSpeed Performance ReportMerging #9743 will not alter performanceComparing Summary
|
71c297f
to
adf7cfe
Compare
b72d997
to
1d31d94
Compare
1d31d94
to
b4a0ac7
Compare
Marking as draft until I can accommodate changes from #9760. |
b4a0ac7
to
909284b
Compare
I am sorry, I had not time this weekend to check if this works as expected :) |
No rush. I was looking at implementing this for IntelliJ and it has me second guessing my approach. Should the client be sending the initial configs that are found OR should the language server search the root_uri for this instead? I'm not sure how much filesystem access should be done from the language server, which is why I did it this way originally. Maybe it's a non-issue though. |
909284b
to
8052ca5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the client be sending the initial configs that are found OR should the language server search the root_uri for this instead?
My first idea was to do all the work on the server side, but after reading about the LSP Specification:
Servers are allowed to run their own file system watching mechanism and not rely on clients to provide file system events. However this is not recommended due to the following reasons:
- to our experience getting file system watching on disk right is challenging, especially if it needs to be supported across multiple OSes.
- file system watching is not for free especially if the implementation uses some sort of polling and keeps a file system tree in memory to compare time stamps (as for example some node modules do)
- a client usually starts more than one server. If every server runs its own file system watching it can become a CPU or memory problem.
- in general there are more server than client implementations. So this problem is better solved on the client side.
Tested it today and it worked 🥳
Based off of #9739.