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 client.name (falling back to client.id) 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
    require('vim.lsp.log').set_format_func(vim.inspect)
  end

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.

2 Likes

@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.

Thanks!