The depth of auto-signature-help

[ixxie]

I like the auto-signature-help feature, but it currently has a major drawback: it's applied regardless of how deep you are in the function.

Consider the scenario where you pass a large object to the function; this is common in configuration functions, like defineConfig from Vite:

As you can imagine, this becomes incredible annoying: the signature help is continuously displayed as you edit the configuration object.

Having auto-signature-help be shallow could resolve it: if the cursor is immediately inside the function signature, you render the help, but if it is deeper, e.g. inside an object nested inside the signature, than it is not rendered.

If this is usecase dependent it could be a configuration option, but I would argue it should be shallow by default.

My be related to #9144 and #5827 but I am not sure how those are scoped.

[kirawi]

I realize this was brought up on Matrix a few years ago but never in an issue to the best of my memory, but we wanted to implement VSCode's algorithm (which I believe is fairly trivial) to determine when to open the signature-help menu. Working in Python made me understand how horrible the system currently is.

https://github.com/microsoft/vscode/blob/151ef3514e76629f4e7bf3951439b1e0dae0a6e5/src/vs/editor/contrib/parameterHints/browser/parameterHints.ts#L23 might be it

[kirawi]

On second thought, we probably really don't need to care what VSCode does as long as we ensure that the behavior is predictable and unobtrusive.

[samuelselleck]

Looking at the VSCode implementation it seems to rely on LSP trigger reasons/trigger characters. The current implementation of signature help in helix doesn't seem to provide the LSP with this information (see SignatureHelpContext missing at helix-lsp/src/client.rs:1085 in the function text_document_signature_help). I'm guessing that this is how the LSP can make the call to not to show signature help in nested objects based on SignatureHelpTriggerKind and document position.

I'm not sure how well this maps to modal editors - I personally like that signature help shows up when entering insert mode. Maybe it would be possible to make "enter insert mode" behave as a "virtual" trigger character? Not very familiar with the LSP spec and have no idea if that is reasonable.

I looked at how it could be approached from the client side as well using tree-sitter (checking the node depth compared to the "function argument" parent node, and variants). The problem with this is that signature help is provided for other types as well (for example rust structs), and the grammar name for a function can vary between languages. It might be possible to use this approach by introducing language specific config for "tree sitter nodes that are treated as signature help roots", but this doesn't feel very robust.