LSP debugging best practices

I have spent far too much time trying to fix issues with various LSP servers (using builtin nvim LSP client). The debugging techniques I know of are arduous and unsatisfactory:

  • vim.lsp.set_log_level('debug')
  • tail -f ~/.cache/nvim/lsp.log
  • Proceed to sift through oceans of barely readable, unformatted JSON in terminal. Bonus: all the different language servers I’m running are mixed together into the same stream.

There must be a better way. Ideally there would be some kind of GUI that:

  • Separates out individual server log streams
  • Formats the JSON so that it is readable

I doubt such a thing exists, though it would be a great tool for learning LSP. But is there some way to log the stream from a single Vim LSP client/server pair? Ideally it would also format the JSON, since LSP messages are extremely difficult to read without this.

  1. Not yet, but this shouldn’t be hard to implement as a logging flag with (falling back to determining separate files. Note, in multi server usescases it might be useful to have the current “temporal ordering” of the single file.
  2. I recommend:
  vim.lsp.set_log_level 'debug'
  if vim.fn.has 'nvim-0.5.1' == 1 then

I changed the log levels recently so debug should give you most the direct RPC logs which IMO is the most valuable.

set_format_func, which I added, will format your debug logs as multiline/json like.

  1. Could be a good usecase for a plugin that integrates with telescope (search logs) + some filtering/highlighting to make the logs more readable.

  2. You’re probably aware of this, but a tmux split with tail -f is invaluable.


@mjlbach Hi there. Thanks for the improvement. Would it be possible to additionally tee the JSON-RPC conversation verbatim into a file?

{"jsonrpc": "2.0", "method": ... }
{"jsonrpc": "2.0", "result": ... }

The weird half-log half-lua-value thing is much less useful for automated analysis than something that can be parsed by a standard json lines parser, and the indentation for the bespoke format seems to be somewhat inconsistent, making human analysis difficult as well.

I haven’t been involved with/actively used neovim in quite awhile (although I do still keep this forum up and running). You’d have to discuss it with @mfussenegger

My bad, didn’t look at the timestamps. I’ll open an issue in the tracker, that’s probably the best way to discuss.