-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Completion block any input #4714
Comments
This looks like a performance problem because of the amount of data that Volar is sending: the completion response is 2.6MB |
Temporary solution: blocking will not happen if you quickly select and close the completion menu. |
Have the same problems, it looks like cause by blocking request of
|
I don't think the server is blocking or deadlocked waiting for the response to The request to resolve the completion item does block in helix on the idle-timeout event. That could be refactored to be done asynchronously |
|
I've also been experiencing this issue with certain autocompletions in Vue files. The suggestions come up instantly, selecting one causes a ~5+ second hang. Not sure if there's any upstream issues (i.e. in volar) for this, but a 2MB+ payload sounds insane, even for autogenerated typings and whatnot. Anyway, happy to test any fixes, I can reliably reproduce this. |
Oh I see what you're saying, it does look like we get deadlocked. Resolving the completion item asynchronously should fix this. |
I'm not sure if there was a regression somewhere, or if the issue is elsewhere, but I've been hitting this again. More specifically: when I select an autocompletion in a Vue file, sometimes all of Helix will hang for 10-20 seconds. I don't have a minimum reproducible case as it seems to happen sporadically, but could something recent have caused this? |
#9668 recently changed completion resolution CC: @the-mikedavis and @pascalkuthe |
That might be too recent to be my issue, looks like I'm running |
we don't resolve anything in the ui loop so I doubt its the same issue. In theory that could be the event system pr but that PR moves even more processing to a background thread so is should have the opposite effect. I would need a reproduction case I haven't noticed anything |
Similarly, I noticed that sometimes hangs appear during autocomplete module import. |
Actually I believe we do still block the UI on resolving completion items: helix/helix-term/src/ui/completion.rs Lines 293 to 300 in cd02976
when accepting a completion item that isn't resolved yet. We also resolve them asynchronously when you've hovered over a completion item for a while. (This was done after the idle timeout since #4781 and now after 150ms since #9668.) So I suspect this is reproducible when you're fast enough to accept the completion item before it is resolved automatically |
Hmm I am not sure that matters. The item is only marked as resolved after the server fulfills the request. So if the server takes 20 seconds to resolve it doesn't matter if you confirm the item within the timeout we would always block. I read the issue as being about selecting completions ( as in scroll up/down) not actually confirming them. For confirming a selection case blocking on resolving them makes sense. We can't apply the completion until the item is resolved altough we could use a more aggressive timeout. |
For what it's worth, I've been seeing this too (with vuels/volar), for as long as I'm using Helix, I believe. Attached you'll find the logs from a verbose-session. LogsPlatformmacOS 14.4 (23E214) Terminal EmulatorAlacritty 0.13.1 (fe2a3c5) Helix Version23.10 (f5d95de) |
Summary
When using the Ctrl+n/p completion menu only vue files(volar lsp), sometimes the helix (any input) is blocked for a few seconds.
Reproduction Steps
record.webm
Helix log
~/.cache/helix/helix.log
[helix-log.log](https://github.com/helix-editor/helix/files/9992674/helix-log.log)Platform
Linux
Terminal Emulator
kitty 0.26.5
Helix Version
22.08.1-428-g5b73c8c7
The text was updated successfully, but these errors were encountered: