-
-
Notifications
You must be signed in to change notification settings - Fork 21
lsp inlay hints #364
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
Comments
Ah I think this is something to be supported by the hls? What kinda thing are the virtual text then? Why are they not supported by neovim proper? Hmmmm As always I’m kinda confused |
Hey 😄 inlay hints and code lenses are different LSP requests. Activity seems to have picked up recently though. |
haskell/haskell-language-server#4131 There’s a GSOC student working on this! |
The virtual text you're seeing are code lenses. It's another LSP specification, which I believe has existed for longer than inlay hints. The main difference is that code lenses come with an action (e.g., you can evaluate doctest snippets, or add imports or type signatures). |
Do you know what’s up with the control sequences and the spaces on code lenses? Is that something that hls does wrong? Or is this something that happens because all of these guys are written for vscode? |
I'm not sure. VSCode does display code lenses differently than neovim, because neovim as a tui doesn't support different font sizes. |
do you just get these as strings? |
haskell-tools doesn't do much, besides enable and auto refresh code lenses by default. |
interesting, why is it that the standard lsp client doesn’t display these then? Also do you know where I’d have to go with these issues? I e what may cause the visual noise displayed in some of the code lenses? |
I think that's just a decision by the maintainer. It could add quite a bit of noise and be too controversial to be enabled by default in neovim core.
I'm not sure there's a good solution to this, because it would involve overriding |
There’s also the case where it renders “line breaks” in inferred type signatures. |
as you can see it inserts these |
Ah, I guess those could be so that it inserts formatted text on multiple lines when you call |
I think so, yes, although it has also reliable been messing up these for me 😂 |
perhaps one could do something like replacing all consecutive whitespaces by one space in the code lenses? I think that would make it look a lot nicer... |
Perhaps. But I think this would have to be implemented in neovim core. Overriding the core function is a dirty hack, and would be brittle. |
argh, that sucks; I don't know if we want to do this in general, do you think i should open an issue in the neovim repo? |
There's an open draft PR that reworks codelens rendering: That might allow overriding the codelens handler properly once it's done. |
Yeah, now I only need to find how, thank you for dropping the link :) |
I went off and fixed it 😅 |
package = pkgs.neovim-unwrapped.overrideAttrs (old: {
patches = old.patches or [] ++ [
(pkgs.fetchpatch {
name = "strip-consecutive-white-spaces.patch";
url = "https://github.com/mangoiv/neovim/commit/ea0a9163cb37e8444465b81abbed82c54134c12e.patch";
hash = "sha256-LQwS+yJucin5AlXTPa3O95Zwjw4RerniPtNT8ctw0AU=";
})
];
}); |
Feature description
It would be super cool if you could support the new lsp inlay hints for code lenses, they look much better than what we have now. I also wonder if there's a possibility to make code lenses look a tad nicer, e.g. not include control sequences and excessive amounts of white space (especially in imports).
This will start working with neovim version 0.10!
Thanks for considering!
The text was updated successfully, but these errors were encountered: