-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for rust-analyzer.inlayHints.typeHints and rust-analyzer.inlayHints.parameterHints #394
Comments
even a variable type hint would be super helpful :) |
As bfredl said, the current |
Type hints in the middle of the line might be a little confusing (what did you type, what is a type hint) or distracting depending on your color scheme. I don't know if the hints would be treated as normal text (how would that work?) but if not, then there might also be unexpected behaviour when you try to move around. I think what is shown in this picture here might be more useful. The type hints just look like regular chaining hints, and appear at the end of the line. This is https://github.com/nvim-lua/lsp_extensions.nvim with nvim-lsp on neovim 0.5. |
@al-jshen ChainingHint is already supported. |
@al-jshen Type hints at the end of the line do not seem like a good idea. In the example you gave, there are two variables and a single type hint. The vars could have different types in certain situations, then having to look at the vars and at the end of the line to do the matching makes it harder. Also, if the line is closer to 80 chars (or 99 in rust's case) you have to deal with li e breaks and thing may get messy. Having a color for the type hints that is different from the color of types should be enough. Many editors do it like that and nobody gets confused. |
This decoration API doesn't seem to bring anything new in the sense of neovim/neovim#9496 and it was noticed long time ago (#256 (comment)). |
I would like to see future support for this feature to allow multiple type hints per line. I'm willing to build this myself, but I'm interested to hear some other opinions on the actual implementation. A simple situation where the current implementation fails: A simple solution might be to create an expanding hint, so |
@the10thWiz a proper implementation would need neovim/neovim#9496 (comment), but as there's no such thing yet, a current possible implementation could involve usage of conceal, as it's often employed in LaTeX, or Haskell. I'm not sure whether conceal can actually be used at all on this case though. |
My suggested (temporary) implementation is to simply add more virtual text to the end of the line. This would likely be assisted by adding multiple separators, one for each type of hint. This would hopefully make it easier to tell what each hint is for. I have actually already implemented my temporary solution, which looks something like this: I do not believe that conceal would be an applicable solution, since virtual text does not (to my knowledge) get syntax highlighting. It might be possible (although difficult and likely not worthwhile) to insert text into the buffer, but prevent it from getting written with the document. It would also need to be stripped out for almost any operation that touches the buffer... An alternate solution for some hints would be to provide them in some type of hover. This would most likely be implemented as a floating window, placed just above the current line, and can contain all the hints for the current line. When/if anti-conceal does stabilize, it would be nice to take advantage of, but until then, we can do reasonably well without. It would be nice to take advantage of param name hints at some point. |
@the10thWiz thanks for your PR, released in v0.21.0. |
So, I have added a little logic to @the10thWiz change just to show the name of the symbol together with its type so it is easier to see and make sense of it. With this, it gets it pretty close to the ideal solution. |
An ideal implementation would look something like If we do want to use |
I think this is too verbose, can we have an option to get rid of the variable name? |
Most case, we will only have one variable, which will give you something like this. struct SomeStruct;
let some_var = SomeStruct; ‣some_var: SomeStruct |
@xltan |
cool, works as expected, thanks👍 |
I think this should be reopened as |
@svenstaro we can't add parameterHints by now because we can't set text/virtual text inline. This needs vim/nvim to add this support. |
Ah, is there some kind of upstream ticket tracking this feature in vim/nvim? |
@svenstaro I don't know. |
Welp, that doesn't look like it's going anywhere soon. Thanks for the reference, though. |
Hello,
With the added support for decorators on NeoVim is it possible to add support for inlay typeHints? Like the screenshot below, where we have chainingHints (already implemented) and then in the last line we have the typeHints (for vars
a
andb
)Thanks!
The text was updated successfully, but these errors were encountered: