| Age | Commit message (Collapse) | Author |
|---|
|
Problem: LSP server message still wrongly handled (after 9.0.1922)
Solution: Handle 'method' messages properly, don't discard them, add
tests.
closes: #13141
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
|
Problem: The Content-Type header is an optional header that some LSP
servers struggle with and may crash when encountering it.
Solution: Drop the Content-Type header from all messages, because we use
the default value anyway.
Because pretty much all popular LSP clients (e.g. coc.nvim, VSCode) do
not send the Content-Type header, the LSP server ecosystem has developed
such that some LSP servers may even crash when encountering it.
To improve compatibility with these misbehaving LSP servers, we drop
this header as well.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Magnus Groß <magnus@mggross.com>
|
|
Problem: Content-type header for LSP channel not according to spec.
Solution: Use "vscode-jsonrpc" instead of "vim-jsonrpc". (Yegappan
Lakshmanan, closes #12295)
|
|
Problem: Tests using IPv6 sometimes fail.
Solution: Use getaddrinfo() and use try/catch. (James McCoy,
closes #11783)
|
|
Problem: Various typos.
Solution: Correct typos. (closes #11432)
|
|
Problem: Large payload for LSP message not tested.
Solution: Add a test with a large LSP payload. (Yegappan Lakshmanan,
closes #10223)
|
|
Problem: Parsing an LSP message fails when it is split.
Solution: Collapse the received data before parsing. (Yegappan Lakshmanan,
closes #10215)
|
|
Problem: Handling LSP messages is a bit slow.
Solution: Included support for LSP messages. (Yegappan Lakshmanan,
closes #10025)
|
