LSP not starting automatically

Language Server Protocol (LSP)
1

LSP doesn’t start automatically anymore for me. I’ve been trying to debug what is happening but haven’t figured out exactly why yet. I’ll list what I know below and hope someone might have some idea:

  • It only seems to happen when opening a file directly in a new session nvim some_file. If instead I open nvim and then :e some_file it starts correctly.
  • LspInfo seems correct and autostart is true.
  • manually triggering with :LspStart works fine.
  • manually triggering with :lua require('lspconfig')['pyright'].manager.try_add() works fine.
  • manually triggering with :doautocmd FileType python works fine.
  • I was then wondering if maybe the autocmd is not triggering correctly for some reason. But adding autocmd FileType python echomsg "hello" correctly shows hello printed when opening a file with nvim some_file.py.

Looking at ~/.cache/nvim/lsp.log I can see that:

  • if I just open a file with nvim some_file and close it again (after waiting some time) only [START][2022-01-14 23:26:19] LSP logging initiated is appended to the log file.
    I’ve seen that the log file is only updated once I exit the file but maybe this always happens.
  • if I manually trigger with LspStart the log file then contains the appended:
    [START][2022-01-14 23:27:20] LSP logging initiated
[ERROR][2022-01-14 23:27:25] .../vim/lsp/rpc.lua:420	"rpc"	fm-langserver"	stderr"	       "2022/01/14 23:27:25 efm-langserver: reading on stdin, writing on stdout\n"
[WARN][2022-01-14 23:27:26] ...lsp/handlers.lua:109	"The language server pyright triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[ERROR][2022-01-14 23:27:26] ...lsp/handlers.lua:442	"stubPath /home/axel/dev/manven/typings is not a valid directory."
[ERROR][2022-01-14 23:27:26] ...lsp/handlers.lua:442	"Exception received when installing recursive file system watcher"
[ERROR][2022-01-14 23:27:28] .../vim/lsp/rpc.lua:420	"rpc"	fm-langserver"	stderr"	       "2022/01/14 23:27:28 jsonrpc2 handler: sending response 2: jsonrpc2: connection is closed\n2022/01/14 23:27:28 efm-langserver: connections closed\n"
  • I’ve tried also without using efm and only pyright but get the same thing so I don’t think the errors above have any impact.

I’m on nightly and using latest lspconfig. I’m using packer but not lazy loading lspconfig.

My lspconfig config is here.

I’m wondering if for some reason the FileType autocmd is triggered when opening the file before lspconfig have added it’s autocmd. This might have something to do with packer but I guess this would then be a problem for many people.

Edit: I can confirm that the above is true by adding a print statement just when lspconfig sets up the autocmd which is printed after the hello from the above FileType cmd.

Edit: Actually adding autocmd VimEnter * doautocmd FileType to my config makes everything work as expected.

2

I just cloned your config. It wouldn’t start (packer wasn’t required by default) and there was an error in nvim-gps about missing treesitter queries. When I corrected that, I opened a bare python file and efm/pyright both started up.

3

Thanks a lot for checking @mjlbach! Yeah I don’t load packer by default, only when I need it to re-compile the config or install new plugins. Not sure what the nvim-gps error was.

I’m wondering if you used my config at the last commit 4c0ab5c7b4c7774767e520eaff6113dba3c25661, since there I’ve added the command autocmd VimEnter * doautocmd FileType. This makes efm/pyright start for me as well but not without it.

If it’s the case that efm/pyright start correctly for you without this but otherwise with the same config I think there is some race-condition and something on my computer is slightly slower or faster.

From what I tried it was clear that the initial FileType autocmd was triggered before lspconfig was loaded and had added its autocmds. Do you know if that’s possible or should that not happen? I’m not sure in which order things should happen at startup.

I’m gonna try to investigate a bit more with smaller examples and reproduce why plugin is loaded after FileType from what it seems.

4

You shouldn’t need that, I tried before 4c0ab5c7b4c7774767e520eaff6113dba3c25661

5

Hmm, okay, I give up for now, I cannot figure out what’s going on. I’ll just keep the autocmd above since it makes it work for me. I’m still confused why lspconfig is loaded after FileType, but was able to reproduce with a minimal config.

6

Lspconfig isn’t loaded after filetype, but a FileType autocommand is used to trigger attaching or starting each language server configuration on which you have invoked setup {}

7

@mjlbach For some reason lspconfig is loaded after filetype in my setup, but I haven’t been able to figure out why yet. I can confirm that this is the case by adding the following to debug statements:

  1. In my config add the autocmds:
    vim.cmd('autocmd FileType * echomsg "filetype event "..&filetype')
vim.cmd('autocmd BufReadPost * echomsg "bufreadpost event"')
vim.cmd('autocmd VimEnter * echomsg "vimenter event"')
  2. Just before the line adding the FileType autocmds in lspconfig (ie here) add the print statement:
    print(
  string.format(
    "autocmd %s %s unsilent lua require'lspconfig'[%q].manager.try_add()",
    event,
    pattern,
    config.name
  )
)

Then if I open a file directly with nvim (nvim some_file) I get the following :messages:

filetype event lua
bufreadpost event
autocmd FileType html unsilent lua require'lspconfig'["html"].manager.try_add()
autocmd FileType tex,bib unsilent lua require'lspconfig'["texlab"].manager.try_add()
autocmd FileType sh unsilent lua require'lspconfig'["bashls"].manager.try_add()
autocmd FileType lua,python,vim,make,markdown,rst,yaml,dockerfile,sh,json unsilent lua require'
lspconfig'["efm"].manager.try_add()
autocmd FileType lua unsilent lua require'lspconfig'["sumneko_lua"].manager.try_add()
autocmd FileType yaml,yaml.docker-compose unsilent lua require'lspconfig'["yamlls"].manager.try
_add()
autocmd FileType xml,xsd,svg unsilent lua require'lspconfig'["lemminx"].manager.try_add()
autocmd FileType c,cpp,objc,objcpp unsilent lua require'lspconfig'["ccls"].manager.try_add()
autocmd FileType dockerfile unsilent lua require'lspconfig'["dockerls"].manager.try_add()
autocmd FileType rust unsilent lua require'lspconfig'["rust_analyzer"].manager.try_add()
autocmd FileType vim unsilent lua require'lspconfig'["vimls"].manager.try_add()
autocmd FileType python unsilent lua require'lspconfig'["pyright"].manager.try_add()
autocmd FileType json unsilent lua require'lspconfig'["jsonls"].manager.try_add()
autocmd FileType kotlin unsilent lua require'lspconfig'["kotlin_language_server"].manager.try_a
vimenter event

where you can see that lspconfig is adding its autocmds after FileType and BufReadPost but before VimEnter.

8

Finally I managed to figure out what was going on! It’s casued by how packer loads plugins.

I my specific case the issue was that nvim-gps was loaded before lspconfig. nvim-gps in turn loads nvim-treesitter by module. So packer starts loading nvim-treesitter and sees that nvim-treesitter has a ftdetect folder, which makes packer trigger a BufRead autocmd at this line.

All this happens before lspconfig and the FileType lspconfig adds are then not executed.

I think the general issue here is that when packer sees that a plugin needs BufRead (since it has eg ftdetect/ftplugin folders) it executes the BufRead event too early. It would probably be better if it does this at then end of packer_compiled.lua. I’ll open an issue for this.

All in all, nothing really to do with lspconfig :slight_smile:

9

Packer issue here: