lahodaj commented on PR #7659:
URL: https://github.com/apache/netbeans/pull/7659#issuecomment-2283734734
So, thinking of this: the `ErrorProvider`s (and most other providers from
the LSP APIs) are registered in the `MimeLookup`, i.e. they are intended for a
specific mime-types. So, solving this at the mime-type seems much more
reasonable than creating a new `isEnabled`, which everyone will need to
implement, and whose implementation will be very tricky.
In other words - there should be an opt-in, based on mime-types. When one
creates a support for new language, say L (e.g. mime-type `text/x-l`), they can
create `ErrorProvider`, `CallHierarchyProvider`, etc., and register them for
their mime-type. And then say, for `text/x-l`, use the providers that are
globally installed. (There may need to be some shenanigans around things like
`CommandProvider`, as those are global.)
This could either be hardcoded in every implementation class in `lsp.client`
(which is mostly what the current changes are doing), or it could simply be a
bridge, so this would look like an ordinary LSP server for most of
`lsp.client`. I would be for the bridge, to separate concerns. The amount of
information we can pass from the provider to the UI is limited by the LSP
anyway, so I don't think I see a strong need to complicate every feature
implementation in the LSP client with the need to support two usecases when it
can support only one (the LSP server one), and there can be a bridge gluing
things together.
All in all, I hope Enso and others wanting to reuse their implementation
could do something like:
```
@RegisterLSPServicesForMimeType("application/x-enso")
package org.enso.tools.enso4igv;
```
or:
```
@RegisterLSPServicesForMimeType("text/x-l")
package org.enso.tools.enso4igv;
```
and all could be handled for them, without the need to do magic stuff in
`isEnabled`.
--
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
