Open michaelpj opened 2 months ago
Do you really want to rely on client detection and fallback on codelens if the client does not support inlay hint? That's additional complexity for a feature which is not mandatory.
Because if you do that, you'll soon want to add codelens as fallback for https://github.com/haskell/haskell-language-server/issues/4211, https://github.com/haskell/haskell-language-server/issues/4212, https://github.com/haskell/haskell-language-server/issues/4213, https://github.com/haskell/haskell-language-server/issues/4214, ...
The thing is, not all clients will support inlay hints. And not all clients even support code lenses! So I do think that the best UX would be something like, for all features that provide code lenses/inlay hints:
That's a bunch of work, of course...
Is your enhancement request related to a problem? Please describe.
At the moment, the explicit import code lenses are quite noisy. Often they take up one line for each line of the import block, doubling its length in the editor.
e.g.
Describe the solution you'd like
Use inlay hints, like so:
Additional context
We can only do this if the client supports inlay hints, so we need to decide based on the client capabilities whether to offer the inlay hints or the lenses as a fallback. I think we probably don't need to make it configurable, since I think the inlay hints will just be superior.