-
-
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
Hang when write-quit #4468
Comments
This is usually because helix waits for the LS to shut down gracefully before quitting. Do you see any error messages after helix quits? |
Also, what version are you running? The write path had big changes in #2267 after the latest release which may change the behavior (although I think that didn't change the waiting for the LS part as dead10ck says). In the future please use the bug report template. |
I have seen the LSP didn't quit timeout error message, but not every time it happens. It also doesn't always happen with the same project. It seems to be fairly random. I have also been playing around with brew and latest master, but we can assume this issue is about the current brew version above. |
So I don't think this is necessarily a bug per se, because it's really in your interest to wait for your LS to shut down gracefully; otherwise, this could potentially lead to your project getting messed up. But there is more that could be done to help with the perception of what's going on. Currently the whole UI just appears to hang because it's happening after we've exited the main event loop that does all the rendering. Perhaps we could use this issue to track improvements we could make. @archseer and I have discussed possibly moving the LSP shutdown procedure earlier, before it exits the rendering loop, and displaying a spinner and a message that the language servers are shutting down. We should also probably make the shutdown timeout configurable for those who would choose to prioritize shutting down more quickly over allowing the LS to shut down gracefully. |
Some ideas:
It's really annoying to open a rust file to change something, then |
Based on my measurements with rust-analyzer, |
This is also a bit harder to do with rust-analyzer which immediately responds to the initialization request, but then will block on the formatting request until it's able to fulfill it. |
Not sure if this is related but the new rust-analyzer update mentions improvements for formatting requests during LSP startup. |
Updated reproduction to reflect Perhaps a spinner to show activity would be helpful here to set expectations |
That looks promising actually 👍🏻 |
My helix constantly hangs with efm-lsp and taplo
efm-lsp
Terminal:
|
EDIT: As pointed out by the-mikedavis, this is #3975. Disregard. Thanks! I think I'm running into this. I have a CSV file with a lot of rows and hx seems to spinlock at 100% during a WQ, even if no 'real' formatting is taking place. Admittedly, the CSV has ~150,000 rows, but I was able to edit it just fine. I've been waiting for wq to finish for about 17 minutes and I see from the tail of the file that it's stuck spinning after writing line 1301. |
helix 22.08.1 (46eb185) I just tested taplo on a small Cargo.toml file and I get a Timed out message when quiting. there are no modifications made. just viewing the file. This isn't the only language server that has this issue. hx Cargo.toml 2022-11-20T09:20:22.979 helix_lsp::transport [ERROR] err <- " INFO taplo: registered request handler method="initialize"\n" |
helix 22.08.1 (46eb185)
|
For taplo this looks like an upstream issue. Taplo is currently discarding LSP shutdown messages. We block awaiting the shutdown response before sending the exit notification but taplo doesn't currently respond to the shutdown request, so we time out. tamasfe/taplo#354 You can see in a verbose log that we wait for a while after the request to shutdown:
Running with taplo built from that PR,
|
Sorry it took so long. helix 22.08.1 (f538b69) efm-ls:
|
Ah that's an interesting one: it looks like we send the shutdown request and the server just exits. The reply to shutdown seems to be discarded by the server since they consider the jsonrpc channel already closed. We can probably handle this by sending |
That behavior should probably be fixed upstream in efm-langserver (the spec says you should exit when you get the |
This issue covers a few cases now:
The remaining case is the hang from trying to auto-format while the server is initializing. For that we have #2059; I'll close in favor of that issue. |
Summary
In some cases (Dart project with active LSP) if you try to
:wq
quit, Helix will hang for 3-5 seconds before quittingReproduction Steps
:wq
Helix log
N/A
Platform
macOS
Terminal Emulator
iTerm Build 3.4.16
Helix Version
helix 22.08.1 (66276ce) (from brew)
The text was updated successfully, but these errors were encountered: