`opts.signature.trigger.show_on_insert` results in permanent signature in js callbacks

[chrisgrieser]

Make sure you have done the following

• [x] Updated to the latest version of blink.cmp
• [x] Searched for existing issues and documentation (try <C-k> on https://cmp.saghen.dev)

Bug Description

When you have opts.signature.trigger.show_on_insert = true, the signature is always shown as long as you are in the callback.

One example is the compare function of Array.sort, where the signature is always shown, as long as I am between the two braces.

code to reproduce:

const foos = []
foos.sort((a, b) => {
	const diff = b.priority - a.priority;
	if (diff !== 0) return diff;

	return 11111
});

Technically, the behavior is correct, however, if you are in long multi-line callback, this type of signature is simply not useful.

Relevant configuration

opts.signature.trigger.show_on_insert = true

neovim version

NVIM v0.11.0

blink.cmp version

1.1.1

[saghen]

I agree but unfortunately I'm not sure we can do much about this since the LSP doesn't tell us the range of the signature help. I've played around with the idea of finding the function but it would be complicated and language specific. Linking #1071 for visibility but not planning on implementing a fix for this

[chrisgrieser]

It might be somewhat hacky & inefficient, but how about detecting multiline by sending another request, but for the position exactly above/below the cursor? If the same signature is returned, then it's a multiline function.

[saghen]

Most LSPs seem to have great performance for the signature help so it could work. If you'd like to give it a shot, I'd be happy to review a PR

[chrisgrieser]

I can take a look later this week.

I took a quick look at the signature module, and from what I can tell, this would be something like creating another emitter that updates the context for the signature trigger, is that correct?

[saghen]

I think the trigger code would remain the same, but it would need to indicate that it was triggered by entering insert mode (see context.trigger in completion/trigger). Then downstream, where the request is made, it would make two requests instead of one and call trigger.hide() if both calls return the same signature

[chrisgrieser]

Upon further investigation, it seems this issue does not arise due to the LSP sending the signature data even in a multi-line callback. Rather, it seems some bug in blink's signature implementation is making additional, wrong calls from another location?

-- debugging keymap just to investigate the available signature at a given location
vim.keymap.set({ "n", "i" }, "<C-s>", function()
	local signatureClient =
		vim.lsp.get_clients({ bufnr = 0, method = "textDocument/signatureHelp" })[1]
	local params = vim.lsp.util.make_position_params(0, signatureClient.offset_encoding)
	vim.lsp.buf_request(0, "textDocument/signatureHelp", params, function(err, result)
		if err then
			vim.notify("Error getting signature help: " .. err.message)
			return
		end
		if not result then
			vim.notify("No signature help available.")
			return
		end
		local firstSig = result.signatures[1].label
		vim.notify(firstSig)
	end)
end)

// snippet with multi-line callback to reproduce the issue
const foos = []
foos.sort((a, b) => {
	const diff = b.priority - a.priority;
	if (diff !== 0) return diff;
	// X <- move cursor here
	return 1;
});

When entering insert mode at the designated location, blink will show the signature of the multi-line callback. When calling vim.lsp.buf.signature_help() or the helper keymap above via <C-s>, there is no signature available. This shows, that the issue is indeed caused by some bug with blink.

[AmadeusK525]

Just ran into this issue today, commenting to get some activity going in the Issue. Unfortunately I don't have time to look into the code right now, but it would be great to have this fixed