Inlay hint as import lens alternative

[michaelpj]

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.

<lens> import Foo (Bar, Baz)
import Foo

Describe the solution you'd like

Use inlay hints, like so:

import Foo <hint begins>(Bar, Baz)<hint ends>

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.

[guibou]

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 #4211, #4212, #4213, #4214, ...

[michaelpj]

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:

1. Have the ability to present either as an inlay hint or a code lens, if both make sense. Based on client capabilities by default.
2. Also provide a code action to trigger the effect of triggering the lens/hint (see e.g. Add a code action provider for the eval plugin (existing code lens) #496 for why this is useful)

That's a bunch of work, of course...

[jian-lin]

It seems this issue should have been closed by #4235.