Support inlay hints

[ulugbekna]

Inlay hints support was added to LSP 3.17:

• spec: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_inlayHint
• related issue in LSP repo: Feature: Inlay Hints microsoft/language-server-protocol#956

What's an inlay hint?

See https://code.visualstudio.com/docs/languages/typescript#_inlay-hints

What's in it for us?

Having type annotations for local definitions as inlay hints would be very nice.

It's not an urgent but quite useful feature, IMO.

References:

• Rust analyzer PR switching to LSP inlay hints: https://github.com/rust-lang/rust-analyzer/pull/11935/files#diff-4bec6bfceb4323ffd0d2ff1ad25070234f084f31ddd5577bbdb510de878a3811

[cemerick]

2¢ after seeing what the inlay hint support looks like via #1159:

• it really will be great to (probably only occasionally as needed) quickly toggle inlay hints as a way to peek at the types of locals without navigating about. Big 👍 there
• The loss of what I'll call "aggregated" top-level signature hints (as provided by code lenses until recently ☠️) is a big blow IMO. Having now experienced not having those hints on top levels, I realize just how much I've come to rely on them, and I don't think that inlays will be a good replacement. Most of us are really well-trained to quickly grok function signatures (e.g. foo -> bar -> string -> 'b and so on), and disaggregating them makes inlays relatively less useful in that function context IMO.

Just as an example, the screenshot from @ #1159 (comment) demonstrates what inlays will look like for a top-level function definition:

Comparing what needs to be parsed for the inlay approach (including all of the always-variable parameter names, etc):

run rpc: State.t Server.t doc: Document.t ...

seems obviously more difficult to parse than the always-familiar notation for OCaml function signatures, State.t Server.t -> Document.t -> ....

It feels like there's a best of both worlds to be had here: inlays for locals, and the familiar format and display for all function definitions (even local functions, perhaps using line-level lenses?).

(I guess that was more like $2 than 2¢, alas 😳)

[jfeser]

I don’t think there’s an issue with keeping the code lenses if people like them. Iirc they were disabled in response to complaints, but a number of people have mentioned that they’d like them back. (Also, they should be possible to enable on the client side. No code has actually been removed; they’re just off by default.)

It’s certainly possible to use both lenses and inlay hints.

[rbjorklin]

Just chiming in to say I really like code lens and want it to stay. I don’t understand the argument for disabling it in the lsp, in vim I can just disable whether or not to display it with a config option?