rust-analyzer sometimes returns a hover result with language being
"text", but there's no syntax/text.vim, so this would fail with:
Error detected while processing function <SNR>150_VimOutputCallback[6]..<lambda>8[1]..ale#lsp#HandleMessage[30]..ale#hover#HandleLSPResponse[42]..ale#floating_preview#Show[13]..<SNR>161_VimShow:
line 13:
E484: Cannot open file syntax/text.vim
Only including the file when it actually exists fixes this.
When 'close_cb' is set for job_start(), but out_cb or err_cb isn't, vim
buffers data instead of dropping it (in case someone wanted to read and
process it in close_cb), and additionally polls for new data every 10
milliseconds, causing excessive wakeups and CPU usage. Since we don't
read the data anywhere outside of out_cb/err_cb, any LSP that prints an
error to stderr triggers this and vim keeps spinning until :ALEStopAllLSPs.
Fix this by always setting both callbacks, thus dropping any data we're
not interested in.
See https://github.com/vim/vim/issues/10758 for an upstream report of
the excessive polling. It's possible this is intentional, I dunno.
Fixes: b42153eb17 ("Fix #4098 - Clear LSP data when servers crash")
According to
https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#textDocument_codeAction,
the response to textDocument/codeAction is:
(Command | CodeAction)[] | null
and the code only handled the case where it was a CodeAction that either
specified an edit or a command, but didn't handle a direct Command.
Note that the specification also says that both can be specified and
then the edit is applied first, then the command. Furthermore, there
seems to be some hacky code handling arguments directly, which I suspect
is non-standard and only works with a specific LSP server that happens
to pass the edits in the arguments unmodified.
Tomáš Janoušek