Look into textDocument/inlayHints

[rwols]

Is your feature request related to a problem? Please describe.
I would like to see inlay hints if possible.

Describe the solution you'd like
Implement microsoft/vscode-languageserver-node#772

Additional context
MetaLS has a custom version of this implemented: scalameta/metals-sublime#36

[predragnikolic]

Inlay hints are now part of the spec.

[jwortmann]

Is there any language server which already has support for the inlay hints from the LSP specs?

I just did an experimental and untested implementation at https://github.com/jwortmann/LSP/tree/inlay-hints, partly based on the feature in LSP-typescript.

Clickable links for the labels are not yet supported, but tooltips should work. According to the specs, the inlay hints can have optional textEdits and commands associated with them too, but I'm not sure how would be a good way to present them in the UI.

---

I guess the linked ST feature request for sublime.LAYOUT_INLINE_RIGHT isn't really relevant for the inlay hints from the LSP specs, because they only have a "Position", and not a "Range" over multiple characters. But there is probably still the issue that the phantoms persist for a short amount of time, when you delete the line / code section containing the inlay hints, until the response for the next request arrives.

[predragnikolic]

LSP-volar supports inlay hints. (Note, you have to tweak the initialization options in LSP-volar to enable inlay hints, also you have to have a vue app that uses typescript version 4.4.+).
LSP-rust analyzer also supports it, but it uses a different request name, experimental/inlayHints, or something like that.

[rwols]

I think with the current behavior of phantoms having inlay hints display for the user as a background request is not ideal. I was thinking of having this LSP feature be implemented as a foreground feature where the user has to press a key binding to do the request. The same key binding would toggle between “show inlay hints” and “hide inlay hints”. Like a temporary X-ray vision. What do you think?

[jwortmann]

Like a temporary X-ray vision. What do you think?

I'm not sure about the solution with a key binding. I could imagine that it would work well if there were "key down" and "key up" events in the ST API, so that the inline hints were only active as long as the key is pressed down. But this is not possible with ST key bindings, so the only option would be the toggle on/off. This would more or less be the same as to add or remove inlayHintProvider to disabled_capabilities with a key binding. Except that the inlay hints would get outdated while you continue with typing, until you manually toggle them off and on again. I could imagine that this would become pretty annoying. Probably it would result for users who want to see the inlay hints, to always have them toggled on. And then after they typed some code, the need to remember to constantly hit the keybinding twice to update the inline hints. I didn't try it in practice though.

[TerminalFi]

LSP-gopls will be supporting inlay hints on next release.

@jwortmann I like your implementation. I did notice that hints are display until document edit. Is this intentional? I would imagine it triggers on document open?

[TerminalFi]

Example:

[TerminalFi]

Like a temporary X-ray vision. What do you think?

I'm not sure about the solution with a key binding. I could imagine that it would work well if there were "key down" and "key up" events in the ST API, so that the inline hints were only active as long as the key is pressed down. But this is not possible with ST key bindings, so the only option would be the toggle on/off. This would more or less be the same as to add or remove inlayHintProvider to disabled_capabilities with a key binding. Except that the inlay hints would get outdated while you continue with typing, until you manually toggle them off and on again. I could imagine that this would become pretty annoying. Probably it would result for users who want to see the inlay hints, to always have them toggled on. And then after they typed some code, the need to remember to constantly hit the keybinding twice to update the inline hints. I didn't try it in practice though.

Hitting a keybinding twice would be a horrible UX in my eyes. is there a FR open with ST to support Key Down and Key Up?

[jwortmann]

Thanks, I will probably try it out with the Go server next weekend. Nice that it seems to work so far, I didn't test my implementation at all ;)

Is this intentional? I would imagine it triggers on document open?

No, just an oversight. Should be easy to fix, so that they appear on document open.

I think I have quickly searched through the ST issue tracker for a feature request about key down/up, but didn't find any. There is such functionality for mouse bindings with "press_command" (mouse button down) and "command" (mouse button released), but unfortunately not for key bindings.

[jwortmann]

By the way, there is another small problem with Sublime's phantoms when you delete a block of code. Because the new inlay hints from the LSP specs don't have a range, but only a position, the phantoms contained in the deleted code won't be removed until the next response from the server arrives. It's not a terrible or breaking bug, but probably feels a bit laggy when it happens. I had created an issue report for this at sublimehq/sublime_text#5410. And I think this problem was already observed with the rust-analyzer implementation.

I think this problem doesn't occur in LSP-typescript, because that language server uses its own inlay hints implementation with a range for the inlay hints.