Closed Integralist closed 2 years ago
I think it's expected for parameter
hints? I'm not (or should not be) doing anything special there, but just to be sure, can you post the output of
lua =vim.lsp.buf_request_all(0, 'textDocument/inlayHint', vim.lsp.util.make_given_range_params({1,0}, {vim.api.nvim_buf_line_count(0), 0}, 0), function(...) vim.pretty_print(...) end)
and tell what's going on in the line of the screenshot? Or check if you have the same behavior on vscode.
The output might be long, you can change the first two arguments passed to make_given_range_params
to restrict its range. They're {row, col}
(1-based index for row, 0 for col).
If it looks right or you have the same behavior on vscode, it might either be a option be something that'll you want to raise at gopls
.
Nothing seemed odd about the output of that command, so I'll likely just close this issue then and presume this is intentional.
If I check inlay hints for one of my Rust programs I see something similar...
e.g. the parameter is inner: T
and the parameter hint also doesn't show the type, just <- (inner)
so if the rust-tools development plugin behaves the same it's more than likely just a protocol thing.
Hello 👋🏻
I'm using this plugin with
gopls
and I noticed that the inlay hints appear incomplete (unless this is by design).For example, in the following screenshot, we can see the function
validatePEMBlocks
accepts an argumentpemType
of typestring
and so I expected the inlay hint to be<- (pemType string)
but it's just<- (pemType)
.