Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lsp: Resolve completion item asynchronously on idle-timeout #4781

Merged

Conversation

the-mikedavis
Copy link
Member

#4406 resolves completion items on the idle-timeout event. The Completion::resolve_completion_item function blocks on the LSP request though, which blocks the compositor and in turn blocks the event loop. So until the language server returns the resolved completion item, Helix is unable to respond to keypresses or other LSP messages.

This is typically ok since the resolution request is fast but for some language servers this can be problematic, and ideally we shouldn't be blocking like this anyways.

When receiving a completionItem/resolve request, the Volar server sends a workspace/configuration request to Helix and blocks itself on the response, leading to a deadlock. Eventually the resolve request times out within Helix but Helix is locked up and unresponsive in that window.

This change resolves the completion item without blocking the compositor.

Closes #4714

d7d0d5f resolves completion items on
the idle-timeout event. The `Completion::resolve_completion_item`
function blocks on the LSP request though, which blocks the compositor
and in turn blocks the event loop. So until the language server returns
the resolved completion item, Helix is unable to respond to keypresses
or other LSP messages.

This is typically ok since the resolution request is fast but for some
language servers this can be problematic, and ideally we shouldn't be
blocking like this anyways.

When receiving a `completionItem/resolve` request, the Volar server
sends a `workspace/configuration` request to Helix and blocks itself
on the response, leading to a deadlock. Eventually the resolve request
times out within Helix but Helix is locked up and unresponsive in that
window.

This change resolves the completion item without blocking the
compositor.
@the-mikedavis the-mikedavis added C-bug Category: This is a bug A-language-server Area: Language server client S-waiting-on-review Status: Awaiting review from a maintainer. labels Nov 16, 2022
@archseer archseer added this to the 22.11 milestone Nov 17, 2022
@archseer archseer merged commit 89efb4f into helix-editor:master Nov 18, 2022
@the-mikedavis the-mikedavis deleted the md-async-resolve-completion-item branch November 18, 2022 18:30
herkhinah pushed a commit to herkhinah/helix that referenced this pull request Dec 11, 2022
…itor#4781)

d7d0d5f resolves completion items on
the idle-timeout event. The `Completion::resolve_completion_item`
function blocks on the LSP request though, which blocks the compositor
and in turn blocks the event loop. So until the language server returns
the resolved completion item, Helix is unable to respond to keypresses
or other LSP messages.

This is typically ok since the resolution request is fast but for some
language servers this can be problematic, and ideally we shouldn't be
blocking like this anyways.

When receiving a `completionItem/resolve` request, the Volar server
sends a `workspace/configuration` request to Helix and blocks itself
on the response, leading to a deadlock. Eventually the resolve request
times out within Helix but Helix is locked up and unresponsive in that
window.

This change resolves the completion item without blocking the
compositor.
freqmod pushed a commit to freqmod/helix that referenced this pull request Feb 8, 2023
…itor#4781)

d7d0d5f resolves completion items on
the idle-timeout event. The `Completion::resolve_completion_item`
function blocks on the LSP request though, which blocks the compositor
and in turn blocks the event loop. So until the language server returns
the resolved completion item, Helix is unable to respond to keypresses
or other LSP messages.

This is typically ok since the resolution request is fast but for some
language servers this can be problematic, and ideally we shouldn't be
blocking like this anyways.

When receiving a `completionItem/resolve` request, the Volar server
sends a `workspace/configuration` request to Helix and blocks itself
on the response, leading to a deadlock. Eventually the resolve request
times out within Helix but Helix is locked up and unresponsive in that
window.

This change resolves the completion item without blocking the
compositor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-language-server Area: Language server client C-bug Category: This is a bug S-waiting-on-review Status: Awaiting review from a maintainer.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Completion block any input
2 participants