-
Notifications
You must be signed in to change notification settings - Fork 4
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
Separate diagnostic statistics from diagnostics needed in the current file(s) #204
Comments
Thanks for reporting! I think this might be useful also in cases that a project has a lot of errors, but I am curious to hear other opinions. What we would need to do here is when sending diagnostics:
I can imagine though that if we don't have too many errors we might be interested in all of them, so maybe we could apply some kind of heuristic? If we have less than 100 errors/warnings/info just send all of it, otherwise apply the algorithm above. |
This sounds OK. Depends a bit in which direction this LSP goes. Is it really fit for more IDE qualities? |
Is your feature request related to a problem? Please describe.
I'm using Metals/Bloop as the tool of choice for a Scala project. This project has many diagnostics, maybe because of Scapegoat compiler plugin which produces a ton of infos. After opening the project I have to wait ~5-10 minutes until all diagnostics are sent to the LSP client. I'm not fully sure what it all sends. I see many diagnostics for 'unvisited files'. Until that is finished working is unstable. Often I have to terminate java processes related to Metals/Bloop to get a stable work environment, i.e. when the LSP client doesn't get a response, resulting in timeouts or completion not working, etc.
Full diagnostics with description texts, etc. are not exactly light weight. For me (and I would be surprised if I would be the only one), I'm only interested in the diagnostics for the file I have open and/or am working in actively.
Having all the other diagnostics cached by the editor seems like a waste of resources to me, in particular when having a local connection where diagnostics can be quickly loaded on demand.
Describe the solution you'd like
I'd like to have a separation between something like diagnostic statistics and the full diagnostics needed for the open files and/or the files that are actively being worked on.
Diagnostic statistics are basically a summary containing how many info, warn and errors a file has. This information can be used in a file explorer, or some other view (depending on the LSP client) that can show information on a per file basis which is not the text editor pane as such. If something like this actually exists.
If the user actually drills down to a particular file the full diagnostics can be loaded.
Full diagnostics are only loaded for open files, or file that are actively being worked on.
Describe alternatives you've considered
I'm not sure if something like the proposed diagnostic statistics actually exist in the LSP protocol.
If not I would still vote for not loading/sending all diagnostics to the LSP client.
Additional context
Search terms:
The text was updated successfully, but these errors were encountered: