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).

[ModProg]

I would love an option to have just all inlay hints of a line joined by | (character could be a setting) after the line, i.e., no language dependent behavior.

Instead of current (the line is truncated because of my editor width):

let (impl_generics: ImplGenerics<'_>, ty_generics: TypeGenerics<'_>, where_clause: Option<&WhereClause>) = self.gener

It would be (inlay hints are truncated):

let (impl_generics, ty_generics, where_clause) = self.generics.split_for_impl(); : ImplGenerics<'_>| : TypeGenerics<'_

[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.

[Jarema]

Adding context from the issue I reported as an idea to change visualisation here, as it didn't link itself here:

After playing for some time with

[editor.lsp]
display-inlay-hints = true

I think that inlay hints would work better if by default, or optionally, could be rendered on the right-hand side of the code, instead of being interleaved with it.

Beyond preference, that would also make it easier to not mess up the indentation and sometimes - the cursor.

vim rust tools uses this approach.

example comparison from async-nats crate:

[qiref]

That is great !!!

[ModProg]

I'd have another idea, have an option to truncate inlay hints if the line gets too long.

Not sure what would be the preferred way to do it, but I imagine just having a setting, that truncates inlay hints if the line is overflowing.

It could in this case truncate inlay hints, adding a … at the end to signal that it was truncated.

[ghost]

Another suggestion: on the top of the line, with the skipping while scrolling, like visual studio.

Pretty much, everywhere except in the code.

In here, check the "5 references| ...".