helix: Hang when write-quit
Summary
In some cases (Dart project with active LSP) if you try to :wq quit, Helix will hang for 3-5 seconds before quitting
Reproduction Steps
- Open reasonably sized Dart project (~300K LOC / ~500 files)
:wq
Helix log
N/A
Platform
macOS
Terminal Emulator
iTerm Build 3.4.16
Helix Version
helix 22.08.1 (66276ce6) (from brew)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 4
- Comments: 23 (18 by maintainers)
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 https://github.com/helix-editor/helix/issues/2059; I’ll close in favor of that issue.
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. https://github.com/tamasfe/taplo/pull/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,
:quitexits in a normal amount of time: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.
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
Errs for all pending_requests in the transport when we see that the stream is closedIf it’s a large file and the language doesn’t have a language server configured and you’re running on 22.08.1 instead of master, that is most likely https://github.com/helix-editor/helix/issues/3975 which was fixed in #2267
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.
That behavior should probably be fixed upstream in efm-langserver (the spec says you should exit when you get the
exitnotification) but in general Helix should be closing outstanding requests when the language server exits anyways: https://github.com/helix-editor/helix/pull/4852@vanarok Can you retest on taplo/efm-lsp now that https://github.com/helix-editor/helix/pull/4797 was merged?
With :q without saving I still have this hang.
Not sure if this is related but the new rust-analyzer update mentions improvements for formatting requests during LSP startup.