Suggestions for inlay hints

[gyreas]

Currently the implementation for inlay hints presents some awkwardness when editing code, for example type hints will cause cursor(s) to "jump" when moving across them. So I'm proposing some workarounds:

• For the currently active line, type hints can be disabled in insert mode, while sparing the other lines, or it can be disabled for the nearest few objects(left and right). This ensures that the hints won't be a distraction during typing as they won't be near
• For type hints that happen to be at the end of the line, they should be rendered before the newline character, and thus circumvent the first suggestion.
• coc.nvim usually display the hints at the end of the line, perhaps borrow this idea for (short) variable definitions/declarations?

This feature is terrific, keep up the good work🖖🏾 Thank you.

[David-Else]

I just toggle them on and off all the time anyway, seems like the easy option:

[keys.normal.space]
i = ":toggle lsp.display-inlay-hints"

[tjkirch]

I'd love to see an option to render type hints at the end of each line rather than in the middle of my code. I find it really distracting when there are big type signatures in the middle of some logic.

[pascalkuthe]

Nvim does this because nvim can't display virtual text inline. And uses language server specific plugins to do so.

Displaying virtual text past the EOL doesn't work well because there are often multiple imkay hints in the same line. It's not clear how they should be rendered (all of them, only some.one of them... which ones?). The details are language dependent and therefore dont belong in core.

Helix only displays whatever the lsp is sending so this would be a feature request for upstream (rust-analyzer).

[tjkirch]

Displaying virtual text past the EOL doesn't work well because there are often multiple imkay hints in the same line

This is the reason it doesn't work well for me in helix - with multiple type hints, it becomes cluttered and I have a hard time seeing the actual code. Even with a single one inline, I find it harder than I'd like.

It's not clear how they should be rendered (all of them, only some.one of them... which ones?). The details are language dependent and therefore dont belong in core.

Wouldn't the answer be to render the final type of the line/expression? If I have result.unwrap() I don't want to see Result<thing> and thing, just thing. If I have let c = a + b I want to see the type of c - I can easily find the types of a and b if needed, but the point of linewise type hints is the type of the line. If an expression spans multiple lines, it can give the type of the expression up to the point of the end of each line, if the language server supports it.

[AstrickHarren]

Toggling on and off seems good to me, especially when I'm trying to write iterators with call chains. It's convenient to be able to see what which step produces iterators of which elements, and use that information for debugging.