jwortmann

I must say that I'm also not a big fan of those modal dialog windows. But as pointed out just a message in the status bar wouldn't really work for...

Here is my opinion: - I would probably be okay with such a change to remove (most of) the dialog windows, which don't require user input. - *if* we want...

> **Question**: is it possible to make that dependency respect config options from this plugin? Or do dependencies "by design" ignore their clients? Yes, should be possible. Just load settings...

I thought about this a bit and I would still vote to not add a new setting for this. I think these messages don't appear very often and for such...

relevant client/registerCapability from the logs formatted as JSON ```json { "registrations": [ { "id": "ee01d1d1-9547-4581-ae65-c564e7fc48c7", "method": "textDocument/diagnostic", "registerOptions": { "workDoneProgress": true, "identifier": "HotReloadDiagnostics", "interFileDependencies": true, "workspaceDiagnostics": true } }, {...

I think we should split this into two separate issues. 1. The design for the dynamic registration implementation is flawed. Currently it assumes that a server can only register for...

I don't use discord. But feel free to open a PR or discuss possible solutions here if you have some ideas. For point 2) an approach could be to pass...

Here is a dirty way how point 1) could work. I haven't tested, though. ```diff diff --git a/plugin/core/types.py b/plugin/core/types.py index b5d5b932..105b3c58 100644 --- a/plugin/core/types.py +++ b/plugin/core/types.py @@ -528,6 +528,13 @@...

I have something in the works / in my mind how the diagnostic streams could be implemented. So if you have a bit of patience I can probably push it...

That is expected. Currently the diagnostic responses would just override each other. You could try wether #2564 works. To be honest, the capability registration and the diagnostic handling should be...