Too many LSP completion requests

[JakeHedman]

Autocomplete in Helix is way slower than neovim and vscode in our typescript project. In some cases when typing fast, my CPU will be pinned at 100% and the completion list won't show until my cursor has been idle for seconds.

This only happens when the LSP is slow to respond to "completion" requests and I keep typing fast before the first "completion" request has resolved. If I stop typing and wait for the completion list to show, subsequent completion is instant like nvim/vscode since helix already has completion items and completes client side.

Looking at the LSP log, helix seems to be sending too many "completion" requests to the LSP. "completion" requests can be really slow in our project so they don't always resolve before the next character is typed.

If the first request has not resolved before a new character is typed, helix will send a new "completion" request for each character typed, overloading the LSP with requests until the user stops typing. Any responses to old requests are discarded with a Tried sending response into a closed channel error.

neovim will wait for the original "completion" request to resolve and not send more requests even if the user continues typing, and then show the results from that request as soon as it arrives.

I have tried different helix versions and messing around with my config without success. Is this user error on my part or a bug in helix-lsp?

I unfortunately do not have steps to reproduce as I have only seen this in our private monorepo.

helix demo:

nvim demo:

[kirawi]

Can you run hx -v and share logs (note that this will reveal text contents of files)? This should have been fixed in #10539

[JakeHedman]

Can you run hx -v and share logs (note that this will reveal text contents of files)? This should have been fixed in #10539

This is a log from typing fauser<Bksp><Bksp>er<Bksp><Bksp>er[...] like in the gif. Lines have been cut to 170 chars for privacy, does it provide any useful information anyway?

Version is latest main (e46cedf)

helix.log

[JakeHedman]

Looks like there are no checks at all for in-progress completion requests, so completion will always be heavily slowed down if the user simultaneously types faster than the LSP responds and slower than the completion-timeout config value.

helix/helix-term/src/handlers/completion.rs

Lines 467 to 474 in 112b287

	register_hook!(move |event: &mut PostInsertChar<'_, '_>| {
	if event.cx.editor.last_completion.is_some() {
	update_completions(event.cx, Some(event.c))
	} else {
	trigger_auto_completion(&tx, event.cx.editor, false);
	}
	Ok(())
	});

The completion menu will not show up at all until the cursor has been idle longer than the LSP takes to respond, and that delay may increase as the LSP gets overloaded by requests from the user typing.