Open automaticp opened 9 months ago
There are also built-in math functions like
that are technically also overloads, but get away with it because they are specified through genType
. Just thought it's worth mentioning.
Just realized, that you mentioned some of this in this comment.
I believe vscode gives a more reasonable UI for signature help, which we should also implement.
Is that capability not supported in neovim?
Is that capability not supported in neovim?
It might be, I've never tried :sweat_smile:
Just realized, that you mentioned some of this in https://github.com/nolanderc/glsl_analyzer/issues/16#issuecomment-1771516666.
I believe vscode gives a more reasonable UI for signature help, which we should also implement.
Yes, the plan is to support this at some point :)
Ohh, I love the new way the builtin overloads show up on hover! No longer it is cluttered by repeated documentation. :grinning:
Hey, I wanted to clarify one thing about the behavior of completion on overloads. Currently (v1.3.2), there's a duplicate entry for each function overload:
I think this is mostly noise and impacts discoverability. Could we maybe consolidate this into a single entry, since the documentation for each overload is still available through hover?
For reference, this is how clangd does this:
Where it says [N overloads] and provides docs for one of them. Now, clangd has full type information, so it can select the right overload on hover:
But it also supports
signatureHelp
(something that's worth considering for glsl_analyzer) to scroll through overloads:For the current state of glsl_analyzer, I think it would help to remove duplicates in completions, but keep the documentation for each overload on hover, so that it's still accessible.
Once type information is available, we can also give the docs for the right overload on hover. The
signatureHelp
could be added without type info for discoverability already, but it won't be able to show the "right/current" overload.