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