Debugging setup issues

[TheMeaningfulEngineer]

I'm having some issues with the nvim language server setion I'm trying to diagnose. Found lsp-status.nvim yesterday which seems like a good start.

If I'm interpreting ti correctly it will give me a response from the language server in vim so I can see if there was an error when things misbehave.

lsp-status.nvim has been previously installed with plug package manager. I'm trying to set lsp-status.nvim with pyls, but the following isn't working:

lua <<EOF    
local lsp_status = require('lsp-status')    
lsp_status.register_progress()    

local nvim_lsp = require'nvim_lsp'    
nvim_lsp.pyls.setup({    
    on_attach = lsp_status.on_attach,    
    capabilities = lsp_status.capabilities})    

EOF    

" Statusline    
function! LspStatus() abort    
  if luaeval('#vim.lsp.buf_get_clients() > 0')    
    return luaeval("require('lsp-status').status()")    
  endif    

  return ''    
endfunction

I'd expect this config would result in an error showing in a status line once is do :vim.lsp.buf.definition() and nothing happens.

Any suggestions on how to debug this?

[wbthomason]

One small clarification: lsp-status does not show information on the LSP client, but rather collects and displays status messages from LSP servers.

In other words, it won't give you an error message when something with your nvim-lsp config is wrong - it shows things like file indexing status, etc. from various language servers.

If that's not what you're after, you may want to take a look at :help lsp-log or :help lsp.

Also, I'm not sure that pyls supports status messages (though pyls_ms does). Your setup for pyls looks correct, though I'm not sure I understand what you mean by "I'd expect this config would result in an error showing in a status line once is do :vim.lsp.buf.definition()". Could you say more about what you're expecting to see?

[TheMeaningfulEngineer]

@wbthomason

One small clarification: lsp-status does not show information on the LSP client, but rather collects and displays status messages from LSP servers.

Thanks, that part is clear.

Also, I'm not sure that pyls supports status messages (though pyls_ms does). Your setup for pyls looks correct, though I'm not sure I understand what you mean by "I'd expect this config would result in an error showing in a status line once is do :vim.lsp.buf.definition()". Could you say more about what you're expecting to see?

Let me zoom out just a bit on what seems to start forming as my goal (and your questions helped me clarify that, thanks :)). I'm looking for the easiest way to debug the language server. Currently I have two ways I can interact with "nvim+language server" (i.e. by running :vim.lsp.buf.definition()):

1. It works
2. It doesn't work and it's silent on why

My initial idea when reaching for lsp-status.nvim was that it would help me understand whats going on in case 2.. Is it not working because:

1. The language server crashed
2. The server is still indexing
3. All is OK and it really cant find a reference
4. All is OK and it really cant find a reference (with extra info showing me where it's looking)

I know it's likely not possible to squeeze all that in a single status line, especially nr.4. I just kind of uncritically spat out my expectations and you could perhaps help me ground them in reality of what lsp-status.nvim can help address. :)

[wbthomason]

Ah, gotcha. So, your best bet for getting server information generally is going to be the log file - you can find the path with :lua vim.lsp.log.get_filename() (and change the log level with :lua vim.lsp.log.set_level({level}) - look at :help lsp-log for more).

lsp-status can display (2) if your language server supports status messages (either $/progress, window/workDoneProgress, or the clangd and pyls_ms extensions). I'd like to have it be able to display (1) and (3/4) too, but it currently does not ((3/4) in particular is often not reported by servers in status messages).

So, tl;dr: lsp-status is unfortunately probably not the tool you need here, particularly with pyls. It would tell you if case (2) was happening for servers that report indexing info (e.g. clangd, pyls_ms, rust-analyzer, and others). Checking case (1) is best done by reading the logs, for now. Checking cases (3/4) is best done by making code where you know the expected outcome, e.g.

foo = 5
bar = foo + 3

should find references for foo.

I hope this helps!

[TheMeaningfulEngineer]

Thanks :+1: