matthiasblaesing commented on PR #7659: URL: https://github.com/apache/netbeans/pull/7659#issuecomment-2287017861
I had another look today, and still think we should revert and reevaluate after release. - I'm not a huge fan on creating APIs/libraries without multiple users. They have the tendency to be onesided and fall out of love. We have a single user (enso), so the question is: How common will Java based LSP be in practice and if they exist how often will they be implemented using NB code and not just LSP4J directly? For the latter case a different kind of LSPBinding implementation might make sense, keeping the implementations separate, but communication in the same process. - Implementing this in `lsp.client` seem arbitrary - the common base is not that big between the two use cases (integration with LSP servers and NB based partitial LSP implentations) - Running the diagnostic routines on any change, might overload the IDE. It was an explicit implementation detail, that there are two levels of diagnostic (error and hint) and these two are run with a 500ms for the LSP server, if I'm not mistaken. - Registration of the `ErrorBridge` is done outside the EDT (call to `putClientProperty`), this might or might not be a problem, but the function is specified to generate `PropertyChangeEvent`s and listeners might expect to be only called from the EDT. - The hack/workaround in `LspCompletionProviderImpl` (check if "real" completion provider is present) is not necessary if the provider would be explicity registered - The changes to the HintsDiagnosticsProvider and the JavaErrorProvider are not needed anymore - The implementation could be done first outside the core, settle down and be integrated later. The impact for the target module would be minimal. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
